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==--