[e2e] Deflating excessive buffers

[Sergey Gorinsky]

   Dear Fred,

   While the loose language is certainly unfortunate, the conflation
arises for a reason: with loss-driven transmission control in end systems
and FIFO queue management with tail drop of packets upon router buffer
overflow, large buffers mean long queues.

   My group proposed a simple architectural solution for deeper queues on
occasion. RD (Rate-Delay) network services partition the router buffer
into R (Rate) and D (Delay) queues: the D queue guarantees short queuing
for delay-sensitive applications, and the R queue offers higher throughput
for throughput-sensitive applications; Podlesny and Gorinsky, "Leveraging
the Rate-Delay Trade-off for Service Differentiation in Multi-Provider
Networks", JSAC, May 2011,
http://fourier.networks.imdea.org/~sergey_gorinsky/pdf/JSAC_Leveraging_Rate
-Delay.pdf .

   Best regards,

   Sergey

On 10/24/14 11:29 PM, "Fred Baker (fred)" <fred at cisco.com> wrote:

>
>On Sep 22, 2014, at 12:17 PM, Martin Heusse <Martin.Heusse at imag.fr> wrote:
>
>> The has been many exchanges on this list about the impact of having
>>excessively large buffers
>
>A point of clarity:
>
>A buffer is a bunch of empty space that you can fill with packets. A
>queue, or a queuing system, is a bunch of packets in a buffer in some
>organized manner.
>
>The historical recommendation that a buffer be able to store at least the
>delay*bandwidth product refers to the size of the empty space that you
>can fill with packets. If I have a satcom link, I¹d actually like to be
>able to push a fair bit of data into it and have that deplete over time
>to fill the available capacity.
>
>The commentary about ³buffer bloat² or "excessively large buffers² is
>about keeping too much in queue. If your queuing system would continuing
>using the entire bandwidth of the link using one packet less of average
>queue depth, in the context of the actual arrival distribution and all
>that, your queue (the set of packets actually in the buffer) is at least
>one packet too deep.
>
>Loose language hopelessly confuses discussions. You would be amazed how
>much time I spend explaining to people that the fact that they want to
>have shallow queues on average doesn¹t imply they shouldn¹t be able to
>store much deeper queues on occasion.
>_______________________________________________
>end2end-interest mailing list
>end2end-interest at postel.org
>http://mailman.postel.org/mailman/listinfo/end2end-interest
>Contact list-owner at postel.org for assistance.