AW: AW: [e2e] Queue size of routers

[Vadim Antonov]

On 20 Jan 2003, Michael Welzl wrote:

> I mean, any type of congestion control should eventually reach
> the BW*delay product as nicely as possible ... smooth, quick,
> stable - and provisioning queue lengths in a way that has
> the mechanism fully saturate the link immediately after a BW
> drop ... I just don't know. It somehow seems to be at odds
> with the idea of probing for the available bandwidth ... and
> it should lead to an unnecessarily long e2e delay. 

Yes, it does.  The end-to-end congestion control loop stability at sub-RTT
time frames and TCP attempting to "fill the pipe" are definitely at odds.

The network seems to work because of combination of several factors:

1) most TCPs out there have relatively small max window sizes

2) the congested points typically are tail circuits

3) because of smoothing of the flows, the probability of congestion in
backbone circuits is relatively low

4) the time it takes for the TCP congestion control algorithm to ramp up
the window to the point where it can start affecting buffers in the very
high speed lines is longer than the duration of most sessions.

This pretty much means that practically any TCP session goes along a path
which is either underloaded (i.e. no congestion, and the flow hits its own
max window size or terminates), or congested at a single place (thus
driving path RTT to 2 * minRTT - because, lacking synchronization between
ingress flows, the average size of queues at other hops along that path
is likely to be <1 packet).

--vadim