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

[michawe at ifi.uio.no (Michael Welzl)]

Hi,

I asked my question like this:

(from Lachlan's last email):
> How are delay measurements more problematic than loss measurements?


and so I wonder, about this issue:

> 2009/11/25 John Heffner <johnwheffner at gmail.com>:
>> Another issue with delay as a signal is that, absent a means to
>> measure one-way delay, it measures the forward and reverse paths
>> together, whereas loss will be from only the forward path.

how this is worse, in this aspect, than loss.

Well, there is a subtle difference in how TCP does it; TCP
is somewhat ignorant to occasional, isolated loss of
ACKs, i.e. traffic on the backward path. But that's how
the protocol operates, it's not an inherent feature of
the metric "loss".

So far, the most convincing argument came from
Damon, in my opinion, about an issue that is
clearly connected to delay only:

On Nov 20, 2009, at 12:33 AM, Damon Wischik wrote:
> Delay is not a reliable indicator in the case of large multiplexers  
> with small buffers. For example, Appenzeller et al. suggested that  
> buffer size should be bandwidth*delay/sqrt(num flows). Under this  
> recommendation, 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. 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.

Interesting.

Cheers,
Michael