[e2e] Question about propagation and queuing delays

[Detlef Bosau]

grenville armitage wrote:
> Detlef Bosau wrote:
>     [..]
> 
>> Just to give one example from there: We recently had a discussion 
>> about "Fastpath". In DSL lines, you need error recovery on the last 
>> mile. Now,  to save overhead you do codespreading/interleaing. Some 
>> "well informed guys" want the ISP to turn interleaving off in order to 
>> spare some "ping time". First of all, it´s simply ridiculous, theat 
>> individual customers without any technical knowledge will prescribe 
>> the provider the appropriate line coding for one individual wire pair.
> 
> 
> I'm curious if you have any stats on the typical error rates that will
> be experienced by the people who switch from Interleave to Fastpath mode

No. I haven´t.

And I expect they will depend heavily on where you are. I don´t think an 
ISP will reveal this to customers.

> on their DSL links. It is certainly true that e.g. gamers find Interleave
> mode to be a pain (at least 20ms additional latency), with good reason.
> Stats on how much packet loss the gamer will experience (in order to gain
> the latency improvement of Fastpath) would be interesting to know. If the
> error rates are low, then in fact it seems like an entirely reasonable
> thing for a customer to desire Fastpath.

If.

The problem is, besides the problem that this may be off topic here in 
this list, so perhaps we should continue this discussion via PM, that it 
is hardly possible to make a decision here without any knowledge of the 
quality of the line.

In addition, from my own professional experience, it is necessary to 
have a clear service description and service level agreement in any sort 
of contract. So, ISP and customer agree upon _WHAT_ is offered and not 
upon _HOW_ it´s implementend.

Particularly the "ping times" are often wunderful "promises", based upon 
"there was an interview with a famous guy on this topic in the 
tabloids...." and then a customer expects a certain QoS. So "fastpath" 
may end up in a hidden, unspoken "unilateral QoS contract".

What happens, if for some reason the latency increases?

As a provider, you must not promise anything what you might not be able 
to keep. It´s always a liability issue. And if one customer is located 
in Markl and the other one in Flensburg, it doesn´t matter where these 
locatins are but there may be a distance of 1000 kilometers in between, 
this is of course diffferent to a situation where both people are 
located in Flensburg. Customer´s typically aren´t aware of this. They 
have read in the tabloids: "Fastpath will gurantee you ping times of 20 
ms." There is not written from where to where. There is only said: "20 
ms". So, when the NASA starts its mission to Mars, you shold enable fast 
path. Then you will have ping times to the spacecraft of 20 ms.


> 
>> Second: Not only these customers may be affected by increasing error 
>> rates: These guys flood large portions of the network with defictive 
>> frames, more precisely with defective ATM cells with corrupted 
>> payload, which is eventually being detected at the customers AAL 5 
>> peer. (At least AFAIK.)
>> This is thoughtless waste of bandwidth, but it is nearly impossible to 
>> convince those guys that this is malicious in quite a number of cases!
> 
> 
> I'm also curious about this "large portions of the network" which is 
> carrying
> useless ATM AAL5 cells. If the bit error rate is so bad that a noticable 
> fraction
> of ATM cells are useless then gamers going to have a bad packet loss 
> rate and
> fairly quickly go back to interleave mode (despite the higher latency). 


When they get aware of this. Until yesterday, DSL 1000 was sufficient 
for online gamers. As of today, customers threaten the providers with 
law suits in order to get "DSL 6000", because otherwise the online game 
won´t work any longer.

It was written in the tabloids, you know.

It´s like computer worms and viruses. These are typical issues in the 
evening news on TV here in Germany.

> Yet if
> the gamers are happy with the typical loss rate using Fastpath, then 
> there's
> probably not that many wasted/useless ATM cells floating around.
> 
> (Naturally, if the actual AAL_PDU loss rate starts to become more than an
> integer of a % the gamer's use of TCP for p2p, web surfing and email 
> becomes
> problematic. But it is hard to argue this by hand-waving - we need stats on
> likely bit error rates a typical DSL customers islikely to see using 
> Fastpath.)
> 

I am totally with you. And even that´s the reason why line coding should 
be left to the provider who _has_ statistics and can make a decision 
based upon them.

It´s what I said before: ISP and customer shall agree upon _what_ is 
provided. Not _hwo_ it´s provided.

However, to get on topic again: Bascially, I talked about DSL as an 
_example_, why  things can get more complex and more complicated than it 
was perhaps in the mids of the 1980s between UCLA, UCSD and UCBE.

Basically, I startet with the question: Why do we expect difficulties 
with TCP in mobile wireless networks? some years ago.

Then, some thousands of papers later and having read tons of paper (is 
there any forest left?) about varying bandwidth, spurious timeouts, 
adverse interactions, scheduling problems and other problems which are 
of course scary - and occur on each and every company LAN with even no 
wireless component in it - I got into the details of TCP timer estimation.

As one would expect, this ended up in the question: Why does the 
Internet work at all?

Obviously, it does.

_I_ want to understand, _if_ and if _why_ there are problems with TCP in 
mobile wireless networks.

It´s not convincing that there are dozens of PhD theses around which 
claim there are problems here, as long as there is no convincing reason 
for this.

Simulations are not convincing (they prove anything and nothing - 
whatever you prefer) and "occasional observation" (recall the "cold 
fusion") aren´t neither.

When we talk about problems with TCP in mobile wireless networks, we 
must give _reasons_ why there could be problems. Anything else is 
playing. And not science.

When you look at my homepage, you´ll find my Path Tail Emulation paper 
there.

I did not write a second paper yet, so a number of obejctions must be 
discussed and a number of corrections must be done in later versions.

However, at the moment, it is not the question _how_ to solve the 
"problem" with TCP in mobile wireless networks. It is the question
_IF_ there is a problem at all. And it is not the question that Ludwig, 
Gurtov, Chrakravorty and thousands of others have written tons of 
papers, there would be some. I have read a great deal of this stuff and 
there are problems in the NS2 caused by HICCUP and this shall make me 
believe there is a problem in reality without NS2 and HICCUP.

Bash me, beat my, excuse me, that is not convincing. Either we identify 
were TCP is vulnerable or were the "system model" assumed by TCP is 
violated by mobile wireless networks - or this all is guess, 
hand-waving. That is the reason why I talked about an "urban legend" 
here yesterday.

You may perfectly say, I would question quite a couple of PhD theses and 
whether it was justified to award the candidates the degree.

If you do so, you perfectly understood what I mean.

What I have read so far on this issue is not convincing - but simply sloppy.

And if I couldn´t do it signicantly better, I wouldn´t write a second 
paper. But _if_ I do, and I´m trying to do so, there must be a sound 
basis in this. And not these "irreproducible observations" and (by NS2) 
"repeated assertions" I´ve read so far.

And an embarrassing example for sloppiness is the "Adaptive Pacing" 
paper by ElRakabawy, Klemm and Lindemann at the Mobihoc this year.

Taking two or three repeated assertations ("simulations") as a proof for 
a fundamental, but questionable, theorem cannot be accepted and I 
wonder, why the paper was by the reviewers.

The paper is nicely written, there are nice figures and tables....
But for the benefit of a conference´s reputation, there should be some 
content in there as well and if the content is correct this is even better.


Detlef





Detlef
-- 
Detlef Bosau
Galileistrasse 30
70565 Stuttgart
Mail: detlef.bosau at web.de
Web: http://www.detlef-bosau.de
Mobile: +49 172 681 9937