[e2e] Question about propagation and queuing delays
detlef.bosau at web.de
Mon Aug 22 11:26:07 PDT 2005
David Hagel wrote:
> This may sound like a naive question. But if queuing delays are so
> insignificant in comparison to other fixed delay components then what
> does it say about the usefulness of all the extensive techniques for
> queue management and congestion control (including TCP congestion
> control, RED and so forth) in the context of today's backbone
> networks? Any thoughts? Are the congestion control researchers out of
> touch with reality?
> - Dave
One answer is: Yes, they are.
A more cynical answer is: If a lucky guy joins a PhD program, he must
find a topic to write about.
In earlier centuries one wrote a doctoral thesis about: "Was Maria
virgin until her first intercourse with..., excuse me, before she became
pregnant?" O.k., now we know about that. Next thesis. "Was Maria virgin
_during_ her pregnancy?". Even that is clear. Next thesis, and this is
anatomiclly interetindg, perhaps one could not only achieve a D.D. but
an M.D. with this: "Was Maria, anatomically correct, virgin after she
gave birth to Jesus?" And now the most difficult one: "Was Maria virgin
_during_ the birth of Jesus?"
No, this is no political incorrect offense to the readers, these are
topics which were discussed extensivley in the Middle Ages, here in
Germany and in Italy and in other locations of the roman catholic church.
Nowadays, we are rationalists. Wie don´t debate Marias virginity.
We discuss the importance of timers for congestion control. Some months
ago, some people from the group around Christoph Lindemann published about
"TCP wit Adaptive Pacing for Multihop Wireless Networks" and reckognized
latency observation as a new crystall ball for congestion forecast and
If this sounds too cyncial: I apologize.
During the last weeks, I became mad about Edge´s paper about adaptive
And the more I´m thinking about that paper and how TCP timers work, the
more I become convinced that the insignificance of queueing delays, and
the consequence that the Internet latency as perceived by a flow is
nearly constant during the lifetime of a flow, is the reason why TCP
timers work at all.
As soon as latencies are subject to large and sudden change, prominent
example: mobile wide area networks, we talk about "spurious timeouts"
and other urban legends, which miss the problem.
The more often I read Edge´s paper and think about ist, the more I play
around with the actual RTT estimators, the more I´m in doubt whether
these will work in a network with highly instable and quickly changing
This is all the more true in mobile wireless networks where latencies
are due to retransmissions and error recovery (without error recovery
TCP flows would break down due to retransmission collapse in those
networks) and therefore subject to change of path properties beyound our
It´s not Edge´s approach, which causes the problem.
It´s our actual approach of RTT estimation which is as useful as cast dice.
So, with respect to your last sentence: We often are out of touch with
reality, because using our actual TCP timers we use an insolid basis for
TCP congestion control which by some chance and lucky cirumstances holds
in contemporary Internet. And when there appear some "strange effects"
in mobile networks, we are glad about it: "Hurray! An effect! A topic
for my PhD thesis!"
Honestly, if you detect fire in your house, you certainly will not be
glad because you can spare fuel but you will call the fire brigade.
Using instable and inappropriate estimators for mean and variance of RTT
leads to a number of "strange effects", "spurious timeouts" is only one
if them. However: It´s a symptom. Not the reason. A cure must focus at
the reason. Not at the symptom.
Once again: In contemporary Internet with neglectible queueing delays
and almost constant paths, this is absolutely no problem and anything
works fine. But falling asleep safe and sound, knowing Kah is around is
perhaps not the best strategy to solve the imminent problem. It´s
similar to our German wellfare system, where polictians ignored (well
known!) problems for decades - and now we face a disaster.
I´m not even convinced that anything is fine in wirebound networks.
Due to some "interesting" discussions here in Germany concerning
"fastpath" (some new buzzword with ADSL) I had a first glance at the ITU
recommendation for g.dmt. In fact, we do not _yet_ use automatic
retransmission here. But if we continue to exploit extremely noisy lines
for high speed data transmission, which appears to be promising when you
look at the market and which allows me as an unemployed person to use
the Internet (with my old ISDN dialup account it was by far to
expensive), things can turn to be different. Perhaps, ARQ might be
useful fore some line. Perhaps not only at the last mile which can be
hidden behind a PEP. We discussed ARQ for satellite links recently in
this list. And then? Will we complain about "spurious timeouts" then?
I apologize when this sounds extremely upset. It´s my honest intention
not to offense anybody. And if I can contribute an approach here, I will
do my very best. I sent some rough ideas to some people, perhas I will
get a feedback about it.
But either I am to stupid too understand TCP and it´s assumptions,
or there is real danger to get into severe trouble when we still ignore
the timer issue.
O.k. I think, I will appl for asylum on the falklands or in the
antarktis now, since I expect to receive evil criticism now.
I don´t mind. If I´m wrong, I will learn my lesson.
But at the moment, I´m simply discouraged.
If I´m wrong, I would appreciate somebody to correct me.
If not, perhpas I can think about a way out. But everytime I start my
editor on my dated, ten years old P160 with 128 MByte memory I think: It
does not matter, whatever I write. As long as I do not provide
billions of simulations (AKA repeated assertions) with the NS2, where I
would have to change great amounts of code which would require man years
of work, even with an equipment where not even a _link_ run for the NS2
would take about half an hour, no one would believe me.
And as an unemployed person who is, as one minor problem of course, in
the need of a job and to make a living here in Germany with admitted 5
millions of unemployed people, in reality whe have probably about 8 to
10 millions of unemployed people here, I cannot rewrite the whole NS2
and insert layer 2 models, which I do not have because no one gives
_real_ channel traces to an unknown guy from Germany, and I cannot
implement all the necessary changes _and_ produce convincing traces
(which again no one would ever believe) on my own.
So, I write one and two lines, and then I shut down the editor and give up.
To blether about "TCP with Adaptive Pacing...." is obviously more
And to ignore the problem is perhaps the best strategy.
Excuse me for writhing this, but as I said, I´m _really_ discouraged.
And may be, I´m completely wrong.
Mail: detlef.bosau at web.de
Mobile: +49 172 681 9937
More information about the end2end-interest