[e2e] Question about propagation and queuing delays
detlef.bosau at web.de
Tue Aug 23 15:09:11 PDT 2005
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.
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
> useless ATM AAL5 cells. If the bit error rate is so bad that a noticable
> 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
> 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
> 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
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
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
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"
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.
Mail: detlef.bosau at web.de
Mobile: +49 172 681 9937
More information about the end2end-interest