[e2e] Question about propagation and queuing delays

[Detlef Bosau]

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


It depends.

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 
avoidance.

If this sounds too cyncial: I apologize.

During the last weeks, I became mad about Edge´s paper about adaptive 
retransmission timeouts.

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 
latencies.

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 
control.

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 
successful.

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.

Detlef


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