<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: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=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@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:0in;
        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.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></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="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Jim-<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Agreed.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">So, I amend my comments to say that there are SEVERAL benefits to pacing – even when using modern queue management algorithms.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Bvs<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" width="815" style="width:407.25pt">
<tbody>
<tr>
<td colspan="3" style="padding:0in 0in 0in 0in">
<p class="MsoNormal"><span style="color:#1F497D"><img width="165" height="110" id="Picture_x0020_4" src="cid:image003.jpg@01D07D04.44FBD3C0" alt="http://www.cisco.com/web/europe/images/email/signature/logo05.jpg"><o:p></o:p></span></p>
</td>
</tr>
<tr>
<td nowrap="" valign="top" style="padding:0in 0in 0in .25in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:8.5pt;font-family:"Arial","sans-serif";color:#666666">Bill Ver Steeg</span></b><span style="font-size:8.5pt;font-family:"Arial","sans-serif";color:#666666"><br>
DISTINGUISHED ENGINEER <br>
versteb@cisco.com<br>
<br>
<o:p></o:p></span></p>
</td>
<td width="50%" valign="top" style="width:50.0%;padding:11.25pt 0in 7.5pt 15.0pt">
</td>
<td style="padding:0in 0in 0in 0in"></td>
</tr>
<tr>
<td colspan="3" style="padding:0in 0in 0in 0in">
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" width="100%" style="width:100.0%">
<tbody>
<tr>
<td style="padding:0in 15.0pt 3.75pt .25in"></td>
</tr>
<tr>
<td style="border:none;border-bottom:solid #CCCCCC 1.0pt;padding:0in 0in 0in 0in">
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span lang="EN-GB" style="color:#1F497D;display:none"><o:p> </o:p></span></p>
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" width="600" style="width:300.0pt">
<tbody>
<tr>
<td style="padding:0in 15.0pt 0in .25in">
<p class="MsoNormal"><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#009900"><o:p> </o:p></span></p>
</td>
</tr>
<tr>
<td style="padding:5.25pt 15.0pt 4.5pt .25in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#999999"><o:p> </o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> gettysjim@gmail.com [mailto:gettysjim@gmail.com]
<b>On Behalf Of </b>Jim Gettys<br>
<b>Sent:</b> Wednesday, April 22, 2015 1:54 PM<br>
<b>To:</b> Bill Ver Steeg (versteb)<br>
<b>Cc:</b> Steinar H. Gunderson; luca.muscariello@orange.com; bloat<br>
<b>Subject:</b> Re: [Bloat] Pacing ---- was RE: RE : DSLReports Speed Test has latency measurement built-in<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Actually, fq_codel's sparse flow optimization provides a pretty strong incentive for pacing traffic.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If your TCP traffic is well paced, and is running at a rate below that of the bottleneck, then it will not build a queue.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It will then be recognized as a "good guy" flow, and scheduled preferentially against other TCP flows that do build a queue (which is what happens today, with TCP's without pacing).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">                                                  - Jim<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Apr 22, 2015 at 10:05 AM, Bill Ver Steeg (versteb) <<a href="mailto:versteb@cisco.com" target="_blank">versteb@cisco.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Actually, pacing does provide SOME benefit even when there are AQM schemes in place. Sure, the primary benefit of pacing is in the presence of legacy buffer management algorithms, but there are some additional benefits when used in conjunction
 with a modern queue management scheme.<br>
<br>
Let's conduct a mind experiment with two rate adaptive flows competing at a bottleneck neck on a very simple one hop network with very short RTT. The results map into your topology of choice. As in most rate adaptive protocols, there are N rates available to
 the receiver. The receiver fetches a chunk of data, observes the receive rate and decides the resolution of the next chunk of data that it fetches. It up shifts and down shifts based on perceived network conditions.<br>
<br>
<br>
First, the unpaced version<br>
On the idle link, let's start both flows - with a small offset in time between them. The first flow will HTTP get a small chunk of data at a very low resolution, and will get the data at the line rate. The second one will then get a small chunk of data at a
 very low resolution, and will also get the data at the line rate. What will each adaptive bitrate algorithm think the available BW is? They will both think they can run at the line rate...... They both decide to upshift to a higher rate. Maybe they go to the
 next resolution up, maybe they go to just below the line rate. Rinse and repeat at various rates, with the square wave receiving patterns overlapping anywhere from 0% to 100%. When the flows do not 100% overlap in time, each client overestimates the link capacity.
 So,  the apparent rate (as seen by the adaptation logic on the client) is misleading.<br>
<br>
Now the paced version<br>
On the idle link, let's start both flows- with a small offset in time between them. The first flow gets a small chunk of data at a very low resolution, but the data is paced at certain rate (could be the next higher rate in the manifest file for this asset,
 could be the highest rate in the manifest file, could be 1.x times one of these rates, could be some other rate....). The second one will then get a small chunk of data at a very low resolution, also  at a deterministic paced rate.  The data will arrive at
 the client at either the rate they requested or slower. The flows tend to be dispersed in time, and "defend their turf" a bit. The likelihood of a gross mis-estimation of spare link capacity is decreased.<br>
<br>
Note that this is definitely a second-order effect, and one has to think about how such flows compete against the more aggressive "send as fast as you can" algorithms. It seems that there would be a control theory approach to solving this problem. Hopefully
 somebody with better math skills then me could quantify the effects.<br>
<br>
There is a bit of game theory mixed into the technical analysis. I have been playing around with this a bit, and it is (at the very least) quite interesting....<br>
<br>
<br>
Bill Ver Steeg<br>
DISTINGUISHED ENGINEER<br>
<a href="mailto:versteb@cisco.com">versteb@cisco.com</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:bloat-bounces@lists.bufferbloat.net">bloat-bounces@lists.bufferbloat.net</a> [mailto:<a href="mailto:bloat-bounces@lists.bufferbloat.net">bloat-bounces@lists.bufferbloat.net</a>] On Behalf Of Steinar H. Gunderson<br>
Sent: Wednesday, April 22, 2015 12:00 PM<br>
To: <a href="mailto:luca.muscariello@orange.com">luca.muscariello@orange.com</a><br>
Cc: bloat<br>
Subject: Re: [Bloat] RE : DSLReports Speed Test has latency measurement built-in<br>
<br>
On Wed, Apr 22, 2015 at 03:26:27PM +0000, <a href="mailto:luca.muscariello@orange.com">
luca.muscariello@orange.com</a> wrote:<br>
> BTW if a paced flow from Google shares a bloated buffer with a non<br>
> paced flow from a non Google server,  doesn't this turn out to be a<br>
> performance penalty for the paced flow?<br>
<br>
Nope. The paced flow puts less strain on the buffer (and hooray for that), which is a win no matter if the buffer is contended or not.<br>
<br>
> fq_codel gives incentives to do pacing but if it's not deployed what's<br>
> the performance gain of using pacing?<br>
<br>
fq_codel doesn't give any specific incentive to do pacing. In fact, if absolutely all devices on your path would use fq_codel and have adequate buffers, I believe pacing would be largely a no-op.<br>
<br>
/* Steinar */<br>
--<br>
Homepage: <a href="http://www.sesse.net/" target="_blank">http://www.sesse.net/</a><br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>