[Tmrg] Now, where were we...?

[lachlan.andrew at gmail.com (Lachlan Andrew)]

2009/11/20 Damon Wischik <d.wischik at cs.ucl.ac.uk>:
> Michael Welzl wrote:
>> Can delay ever be worse as a congestion indicator than
>> loss is? What kinds of misinterpretations can we have,
>> if we carefully interpret it?
>
> Delay is not a reliable indicator in the case of large multiplexers with
> small buffers.  if the number of flows is very large then the maximum
> possible queueing delay is very small, and it may be small enough to be
> swamped by things like timer granularity.

Absolutely.  We shouldn't rely on absence of delay as absence of congestion.

Even "purely loss based" congestion control pays   some   attention to
delay, through ACK-clocking:  If the delays become huge, the rate
reduces a little.  It would be dangerous to have a delay-based
congestion control which didn't consider loss too.

> Packet loss should simply be
> (x-C)/x where x is the total load and C is the link speed, assuming that
> there are many flows and they are desynchronized, and this should
> continue to be a reliable indicator of congestion no matter how many
> flows there are.
>
> What I've written only applies to large multiplexers with small buffers.
> It doesn't apply to access links, where I can well believe that delay is
> an appropriate congestion indicator.

Yes, and the end system is probably receiving signals from   both
types of links.  The challenge is to listen to both at the same time.
(For TMRG, the challenge is to develop "models to evaluate" mechanisms
which listen to both; we're not allowed to develop mechanisms :)

Fortunately, the "delay noise" from core links is negligible compared
with the signal from access links.  A bigger challenge may be middle
boxes can introduce delay-noise.  Conversely, "loss noise" caused by
physical layer losses can easily overwhelm the "loss signal" from a
high-speed link.

Cheers,
Lachlan

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan>
Ph [phone]