<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Texto de balão Char";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:36.0pt;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EstiloDeEmail17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.TextodebaloChar
        {mso-style-name:"Texto de balão Char";
        mso-style-priority:99;
        mso-style-link:"Texto de balão";
        font-family:"Tahoma","sans-serif";}
.MsoChpDefault
        {mso-style-type:export-only;}
@page Section1
        {size:612.0pt 792.0pt;
        margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.Section1
        {page:Section1;}
/* List Definitions */
@list l0
        {mso-list-id:56704280;
        mso-list-type:hybrid;
        mso-list-template-ids:-1148278648 -1346070502 68550659 68550661 68550657 68550659 68550661 68550657 68550659 68550661;}
@list l0:level1
        {mso-level-start-at:0;
        mso-level-number-format:bullet;
        mso-level-text:\F06E;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Wingdings;
        mso-fareast-font-family:"Times New Roman";
        mso-bidi-font-family:"Times New Roman";}
ol
        {margin-bottom:0cm;}
ul
        {margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=PT-BR link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Paddy,<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I’m sorry, but I am afraid I have to strongly disagree
with Antonov´s view on buffer length needs, and perhaps with most people´s
opinion on this list.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>About buffer sizes on routers, I suggest you look for Nick
McKeown’s presentation “<b>Buffers:</b> How we fell in love with
them, and why we need a divorce”. It makes sense to me.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>IMHO, most of you seem to make confusion between buffers needed
at the *ends* of a TCP connection, and buffers needed middle way. At the ends,
where congestion is detected, and TCP anti-congestion mechanisms act, large
buffers are necessary when you want to obtain a high bit rate over a long round
trip delay path.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>This has nothing to do with buffers <b>within</b> routers. A lot
of flows flow through a backbone router. Some of them have large BW, same have
very little BW. Some of them have very very far endpoints, some of them come
from the host in the other side of the town. The router has no clue on the
BW.delay product of each flow, and cannot buffer accordingly – supposing
this could help someway.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In his text, Antonov says that buffers add
“inertia”. This does not seem true. In physical systems, inertia is
added by mass. Buffers are more like springs. If you think of a car suspension,
a buffer too long is like a suspension too soft. Maybe good to isolate from
road irregularities, but quite unstable.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>As buffers grow large, the information about congestion takes
longer time to come back to a TCP sender, what makes the system less stable
(not more stable), and more prone to oscillatory behavior.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>My vision of what a router does: what a router sees are output
interfaces, with a given bandwidth and some characteristics. Under light
traffic, the output queue will be almost always empty, at most with a sending
packet and another waiting. If the integration of multiple flows traversing
that output interface gets close to the maximum bandwidth of the interface, and
the system is close to a stable situation, some probability distribution
function must exist that can describe the queue length. Without any
mathematical proof, I dare to say that the average queue length in this
condition should be of a few (less than 10?) packets. Some fluctuations can
occur due to slight changes in traffic load, and since that does not mean
“congestion”, there must be enough buffer to keep these few packets
in the game. But when the number of packets waiting to be transmitted rises
above a certain limit (20? 40?) packets, this is seen by the router as sign
that there are more flows trying to cross that output interface than it can
accommodate. So … time to start dropping some packets, and make a few
transmitting TCP guys to slow down. The buffer must have the proper size to drop
packets when there is a probable congestion, and do not drop packets under
normal fluctuations. Where does delay considerations get here? They
don’t.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo1'><![if !supportLists]><span
lang=EN-US style='font-size:11.0pt;font-family:Wingdings;color:#1F497D'><span
style='mso-list:Ignore'>n<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span
lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Alexandre.<o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> <o:p></o:p></span></p>
<p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>De:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> end2end-interest-bounces@postel.org
[mailto:end2end-interest-bounces@postel.org] <b>Em nome de </b>Paddy Ganti<br>
<b>Enviada em:</b> sexta-feira, 19 de junho de 2009 16:20<br>
<b>Para:</b> end2end-interest@postel.org<br>
<b>Assunto:</b> [e2e] Why Buffering?<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal>For the question of "why do routers buffer", Vadim
Antonov provided the following rationale (<a
href="http://www.irbs.net/internet/nanog/0204/0298.html">http://www.irbs.net/internet/nanog/0204/0298.html</a>)<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>---------------------------------------------------------------------------------------------------------------------------------------------------------<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>Well, so far nobody provided a valid explanation for the
necessity of <br>
buffering in routers (and any other stochastically multiplexing devices). <br>
<br>
The real reason for having buffers is the fact that information about <br>
congestions takes some time to propagate. (In TCP/IP congestion are <br>
detected by seeing lost packets). <br>
<br>
If buffers are not sufficient to hold packets until TCP speakers see <br>
congestion and slow down, the system becomes unstable. Buffers are, <br>
essentially, inertial elements in the delayed negative-feedback control <br>
loop. Insufficient inertia causes oscillations in such systems, which is <br>
sometimes useful, but in case of networks leads to decreased througoutput <br>
because the wire is utilized fully only at upswings and underutilized on <br>
downswings (collapsed TCP windows aggravate the effect futher). <br>
<br>
Consequently, the holding capacity of buffers should be sufficient to <br>
bring the inertia of the system up to the reaction time of the negative <br>
feedback (this is a simplification, of course). This reaction time is <br>
about one round-trip time for end-to-end packets. <br>
<br>
In real networks, the RTTs differ for different paths, so some <br>
"characteristic" RTT is used. So, to hold packets until TCPs slow
down a <br>
router needs cRTT * BW bits of buffer memory (where BW is the speed of the <br>
interface). This rule can be somewhat relaxed if congestion control loop <br>
is engaged proactively before congestion occured (by using Random Early <br>
Detection), but not much. <br>
<br>
Even with properly sized buffers, sessions with longer RTTs suffer from <br>
congestions disproportionately because TCPs on the ends never get enough <br>
time to recover fully (i.e. to bring windows to large enough size to <br>
maintain steady stream of packets), while small-RTT sessions recover <br>
quickly, and, therefore, get bigger share of bandwidth. But I'm <br>
digressing :) <br>
<br>
--vadim<br>
-------------------------------------------------------------------------------------------------------------------------------- <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>My question to the group is : what other reasons not
mentioned here can be reasons to buffer in a router?<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>-Paddy <o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>