AW: AW: [e2e] Queue size of routers

[Michael Welzl]

Hi all,

I just noticed:

> > The previous result is related to the "sawtooth" variations of TCP's
> > congestion window, and it can be roughly explained as follows:
> > after a (single) packet loss cwnd will be decreased by
> > a factor of 2. To keep the link saturated after the loss,
> > we need to maintain a send window of at least C*T, which means
> > that before the loss cwnd should be at least 2*C*T. This will be the
> > case if we have C*T bytes in the buffer of the bottleneck link,
> > and C*T more bytes in the "wire" (please send me a note if
> > you would like to receive a (still incomplete..) draft that
> > discusses this problem in more detail).

... to me, even if it may lead to TCP being capable of obtaining
more throughput, this sounds like overprovisioning in terms of
queue length ... like designing for a network where queues are
seen as part of the capacity and should always be filled.

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. As David
Reed pointed out, it may be better to keep queues small because
TCP needs to be notified early in order to be able to react
properly. Just my opinion ... although such a configuration
may work well in certain cases?!

Cheers,
Michael