Re: Deflating excessive buffers

"Fred Baker (fred)" <[email protected]> Fri, 24 Oct 2014 22:29:27 +0000
Newsgroups gmane.network.end2end
Message-ID <[email protected]>
--===============2134001084==
Content-Language: en-US
Content-Type: multipart/signed;
	boundary="Apple-Mail=_676007B5-13A4-4158-8527-73E8ED65962F";
	protocol="application/pgp-signature"; micalg=pgp-sha1

--Apple-Mail=_676007B5-13A4-4158-8527-73E8ED65962F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Sep 22, 2014, at 12:17 PM, Martin Heusse <[email protected]> =
wrote:

> The has been many exchanges on this list about the impact of having =
excessively large buffers=20

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=92d 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 =93buffer bloat=94 or "excessively large buffers=94 =
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=92t imply they shouldn=92t be able =
to store much deeper queues on occasion.

--Apple-Mail=_676007B5-13A4-4158-8527-73E8ED65962F--

--===============2134001084==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
end2end-interest mailing list
[email protected]
http://mailman.postel.org/mailman/listinfo/end2end-interest
Contact [email protected] for assistance.

--===============2134001084==--