From touch at isi.edu  Tue Oct 21 18:47:03 2014
From: touch at isi.edu (Joe Touch)
Date: Tue, 21 Oct 2014 18:47:03 -0700
Subject: [e2e] updated E2E list advisory board
Message-ID: <54470C97.2020506@isi.edu>

Hi, all,

Henning Schulzrinne and Scott Brim's terms as members of the
E2E-Interest email list Advisory Board have completed. Although we had
no significant email issues during that time, I would like to thank them
for offering their service.

I'd also like to welcome Fred Baker and Wes Eddy as new members to the
advisory board, hoping that their service is similarly uneventful.

Thanks to all,

Joe (as list admin)

From fred at cisco.com  Fri Oct 24 15:29:27 2014
From: fred at cisco.com (Fred Baker (fred))
Date: Fri, 24 Oct 2014 22:29:27 +0000
Subject: [e2e] Deflating excessive buffers
In-Reply-To: <A9DA72E4-20BD-4C44-8853-88CC3E5BF7EE@imag.fr>
References: <A9DA72E4-20BD-4C44-8853-88CC3E5BF7EE@imag.fr>
Message-ID: <1208BDF7-C140-42B2-872D-6882913B18A2@cisco.com>


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.

From sergey.gorinsky at imdea.org  Mon Oct 27 06:17:04 2014
From: sergey.gorinsky at imdea.org (Sergey Gorinsky)
Date: Mon, 27 Oct 2014 14:17:04 +0100
Subject: [e2e] Deflating excessive buffers
In-Reply-To: <1208BDF7-C140-42B2-872D-6882913B18A2@cisco.com>
References: <A9DA72E4-20BD-4C44-8853-88CC3E5BF7EE@imag.fr>
	<1208BDF7-C140-42B2-872D-6882913B18A2@cisco.com>
Message-ID: <D073F5F5.281FF%sergey.gorinsky@imdea.org>


   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.