[e2e] Question about propagation and queuing delays
puddinghead_wilson007 at yahoo.co.uk
Tue Aug 23 00:47:55 PDT 2005
How is this for a thesis in older times
If the equator and the latitudes was totally
aligned/in parallel with the plane of the revolution
of the earth is daylight saving times needed?
(neevrmind that latitudes may be ellipses)
--- Detlef Bosau <detlef.bosau at web.de> wrote:
> 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
> 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
> 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
> 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
> 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
=== message truncated ===
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
More information about the end2end-interest