[e2e] RES: Why Buffering?

[Lachlan Andrew]

2009/6/24 Jon Crowcroft <Jon.Crowcroft at cl.cam.ac.uk>:
> In missive <4A40FC9F.9060504 at web.de>, Detlef Bosau typed:
>
>  >>Jon Crowcroft wrote:
>  >>> the naive argument for bw*delay buffer
>  >>> was that AIMD involves rate halving=20
>
>  >>It's not the rate being halved but the congestion window.
>
> that's why i said "naive" argument:)
>
> the rate does halve over a v. long (lotsa rtts) (well, the arrival
> rate at the bottleneck) - the packet rate thru the bottleneck
> obviously can't exceed the capacity;)

ACK clocking means that the arrival rate equals the packet rate, over
a long time.  The arrival rate is halved if the buffer is negligible,
but not if the buffer is large.

>  >>Surely not a different one for any possible flow.
>
> removing the RT dependence in TCP congestion window is a goal of quite
> a few researchers...

It is an easily achieved goal; there are lots of schemes which make
the rate independent of the RTT.  However, it is a moot point, since
the call for BDP buffers is also easily fixed by small changes to TCP.

The real motivation for large buffers is minimising complaints from
customers.  If a handful of important customers buy cards and use them
to send a few TCP (Reno) flows over a long-RTT path, then the cards
that those customers buy have to have "big" buffers to get high
throughput.  That causes Cisco to design for 100ms of buffering.  (Not
"one RTT", which is ambiguous, as Detlef pointed out.)

>  >>So, after a long list of scenarios where Alexandre is right: Is there a
>  >>scenario, where he is wrong? ;-)
>
> probably.....

Yes, the one I listed earlier in this thread:  A small number of
long-lived Reno-like flows with large BDPs are bottlenecked at this
router.  Most routers don't carry this load, but when it was cheap to
put in enough memory, it was a common enough case to influence router
design, for better or worse (but not 'til death do us part).

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 +61 3 9214 4837