[e2e] RES: Why Buffering?

[Jon Crowcroft]

of course if you have a bottleneck rate of R
and a max rate somewhere else of R-epsilon
and a receive ack rate of R-delta
then you can't exceed R by much either

so in reality, think of a DSL line with 8Mbps downlin and 384kbps
uplink speed (or throttling)
and a well-tempered network where the share of a bottlneck is close to
to the share of links either side....
then when you have a send window of W, you get W acks, which, 
packet conservation allowing, lets you send W + W packets
but not in the same time - in some longer time (quite a lot 
more than 1 RTT - if delta or epsilon are small) 
so then your rate creeps slightly above the output rate of the
bottleneck share (indeed it may be another flow has fluctuted below
too in this time)

so exogeneous effects may mean you dont need BW*RTT at all of
buffering...

In missive <aa7d2c6d0906241030w323e17fax87929527846e7da7 at mail.gmail.com>, Lachl
an Andrew typed:

 >>2009/6/24 Jon Crowcroft <Jon.Crowcroft at cl.cam.ac.uk>:
 >>> In missive <4A40FC9F.9060504 at web.de>, Detlef Bosau typed:
 >>>
 >>> =A0>>Jon Crowcroft wrote:
 >>> =A0>>> the naive argument for bw*delay buffer
 >>> =A0>>> was that AIMD involves rate halving=3D20
 >>>
 >>> =A0>>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.
 >>
 >>> =A0>>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.)
 >>
 >>> =A0>>So, after a long list of scenarios where Alexandre is right: Is ther=
 >>e a
 >>> =A0>>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
 >>
 >>--=20
 >>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

 cheers

   jon