<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=iso-8859-1"><meta name=Generator content="Microsoft Word 14 (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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri","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;}
/* List Definitions */
@list l0
{mso-list-id:1539052538;
mso-list-type:hybrid;
mso-list-template-ids:1111410986 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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=MsoPlainText>Mr. White,<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>AQM <b>is</b> a great solution for bufferbloat. End of story. But if you want to track down which device in the network intentionally dropped a packet (when many devices in the network path will be running AQM), how are <i>you</i> going to do that? Or how do <i>you</i> propose to do that?<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>The graph presented is caused the interaction of a single dropped packet, bufferbloat, and the Westwood+ congestion control algorithm – and not power boost.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>- Jerry<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>-----Original Message-----<br>From: Greg White [mailto:g.white@CableLabs.com] <br>Sent: Monday, August 25, 2014 1:14 PM<br>To: Sebastian Moeller; Jerry Jongerius<br>Cc: bloat@lists.bufferbloat.net<br>Subject: Re: [Bloat] The Dark Problem with AQM in the Internet?</p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>As far as I know there are no deployments of AQM in DOCSIS networks yet.<o:p></o:p></p><p class=MsoPlainText>So, the effect you are seeing is unlikely to be due to AQM.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>As Sebastian indicated, it looks like an interaction between power boost, a drop tail buffer and the tcp congestion window getting reset to slow-start.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>I ran a quick simulation of a simple network with power boost and basic<o:p></o:p></p><p class=MsoPlainText>(bloated) drop tail buffer (no AQM) this morning in an attempt to understand what is going on here. You didn't give me a lot to go on in the text of your blog post, but nonetheless after playing around with parameters a bit, I was able to get a result that was close to what you are seeing (attached). Let me know if you disagree.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>I'm a bit concerned with the tone of your article, making AQM out to be the bad guy here ("weapon against end users", etc.). The folks on this list and those who participate in the IETF AQM WG are working on AQM and packet scheduling algorithms in an attempt to "fix the Internet". At this point AQM/PS is the best known solution, let's not create negative perceptions unnecessarily.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>-Greg<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>On 8/23/14, 2:01 PM, "Sebastian Moeller" <<a href="mailto:moeller0@gmx.de"><span style='color:windowtext;text-decoration:none'>moeller0@gmx.de</span></a>> wrote:<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>>Hi Jerry,<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>>On Aug 23, 2014, at 20:16 , Jerry Jongerius <<a href="mailto:jerryj@duckware.com"><span style='color:windowtext;text-decoration:none'>jerryj@duckware.com</span></a>> wrote:<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>>> Request for comments on: <a href="http://www.duckware.com/darkaqm"><span style='color:windowtext;text-decoration:none'>www.duckware.com/darkaqm</span></a><o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> The bottom line: How do you know which AQM device in a network <o:p></o:p></p><p class=MsoPlainText>>>intentionally drops a packet, without cooperation from AQM?<o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> Or is this in AQM somewhere and I just missed it?<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>>I am sure you will get more expert responses later, but let me try to <o:p></o:p></p><p class=MsoPlainText>>comment.<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>>Paragraph 1:<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>>I think you hit the nail on the head with your observation:<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>>The average user can not figure out what AQM device intentionally <o:p></o:p></p><p class=MsoPlainText>>dropped packets<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>>Only, I might add, this does not depend on AQM, the user can not figure <o:p></o:p></p><p class=MsoPlainText>>out where packets where dropped in the case that not all involved <o:p></o:p></p><p class=MsoPlainText>>network hops are under said userıs control ;) So move on, nothing to <o:p></o:p></p><p class=MsoPlainText>>see here ;)<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>>Paragraph 2:<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>>There is no guarantee that any network equipment responds to ICMP <o:p></o:p></p><p class=MsoPlainText>>requests at all (for example my DSLAM does not). What about pinging a <o:p></o:p></p><p class=MsoPlainText>>host further away and look at that hosts RTT development over time?<o:p></o:p></p><p class=MsoPlainText>>(Minor clarification: its the load dependent increase of ping RTT to <o:p></o:p></p><p class=MsoPlainText>>the CMTS that would be diagnostic of a queue, not the RTT per se). No <o:p></o:p></p><p class=MsoPlainText>>increase of ICMP RTT could also mean there is no AQM involved ;)<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>> I used to think along similar lines, but reading <o:p></o:p></p><p class=MsoPlainText>><a href="https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Tracero"><span style='color:windowtext;text-decoration:none'>https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Tracero</span></a><o:p></o:p></p><p class=MsoPlainText>>ute _N47_Sun.pdf made me realize that my assumptions about ping and <o:p></o:p></p><p class=MsoPlainText>>trace route were not really backed up by reality. Notably traceroute <o:p></o:p></p><p class=MsoPlainText>>will not necessarily show the real data's path and latencies or drop <o:p></o:p></p><p class=MsoPlainText>>probability.<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>>Paragraph 3<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>>What is the advertised bandwidth of your link? To my naive eye this <o:p></o:p></p><p class=MsoPlainText>>looks a bit like power boosting (the cable company allowing you higher <o:p></o:p></p><p class=MsoPlainText>>than advertised bandwidth for a short time that is later reduced to the <o:p></o:p></p><p class=MsoPlainText>>advertised speed). Your plot needs a better legend, BTW, what is the <o:p></o:p></p><p class=MsoPlainText>>blue line showing? When you say that neither ping nor trace route <o:p></o:p></p><p class=MsoPlainText>>showed anything, I assumed that you measured concurrently to your <o:p></o:p></p><p class=MsoPlainText>>download. It would be really great if you could netperf-wrapper to get <o:p></o:p></p><p class=MsoPlainText>>comparable data (see the link on <o:p></o:p></p><p class=MsoPlainText>><a href="http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferb"><span style='color:windowtext;text-decoration:none'>http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferb</span></a><o:p></o:p></p><p class=MsoPlainText>>loa t ) There the latency is not only assessed by ICMP echo requests <o:p></o:p></p><p class=MsoPlainText>>but also by UDP packets, and it is very unlikely that your ISP can <o:p></o:p></p><p class=MsoPlainText>>special case these in any tricky way, short of giving priority to <o:p></o:p></p><p class=MsoPlainText>>sparse flows (which is pretty much what you would like your ISP to do <o:p></o:p></p><p class=MsoPlainText>>in the first place ;) )<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>> Here is where I reveal that I am just a layman, but you complain about <o:p></o:p></p><p class=MsoPlainText>>the loss of one packet, but how do you assume does a (TCP) settle on <o:p></o:p></p><p class=MsoPlainText>>its transfer speed? Exactly it keeps increasing until it looses a <o:p></o:p></p><p class=MsoPlainText>>packet, then reduces its speed to 50% or so and slowly ramps up again <o:p></o:p></p><p class=MsoPlainText>>until the next packet loss. So unless your test data is not TCP I see <o:p></o:p></p><p class=MsoPlainText>>no way to avoid packet loss (and no reason why it is harmful). Now if <o:p></o:p></p><p class=MsoPlainText>>my power boost intuition should prove right I can explain the massive <o:p></o:p></p><p class=MsoPlainText>>drop quite well, TCP had ramped up to above the long-term stable and <o:p></o:p></p><p class=MsoPlainText>>suffers several packet losses in a short time, basically resetting it <o:p></o:p></p><p class=MsoPlainText>>to 0 or so, therefore the new ramping to 40Mbps looks pretty similar to <o:p></o:p></p><p class=MsoPlainText>>the initial ramping to 110Mbps...<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>>Paragraph 4:<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>>I guess, ECN, explicit congestion notification is the best you can <o:p></o:p></p><p class=MsoPlainText>>expect, or routers will initially set a mark on a packet to notify the <o:p></o:p></p><p class=MsoPlainText>>TCP endpoints that they need to throttle the speed unless that want to <o:p></o:p></p><p class=MsoPlainText>>risk packet loss. But not all routers are configured to use it (plus <o:p></o:p></p><p class=MsoPlainText>>you need to configure your endpoints correctly, see:<o:p></o:p></p><p class=MsoPlainText>><a href="http://www.bufferbloat.net/projects/cerowrt/wiki/Enable_ECN"><span style='color:windowtext;text-decoration:none'>http://www.bufferbloat.net/projects/cerowrt/wiki/Enable_ECN</span></a> ). But this <o:p></o:p></p><p class=MsoPlainText>>will not tell you where along the path congestion occurred, only that <o:p></o:p></p><p class=MsoPlainText>>it occurred (and if push comes to shove your packets still get dropped.)<o:p></o:p></p><p class=MsoPlainText>> Also, I believe, a congested router is going to drop packets to be <o:p></o:p></p><p class=MsoPlainText>>able to ³survive² the current load, it is not going to send additional <o:p></o:p></p><p class=MsoPlainText>>packets to inform you that it is overloaded...<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>>Best Regards<o:p></o:p></p><p class=MsoPlainText>> Sebastian<o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> <o:p></o:p></p><p class=MsoPlainText>>> _______________________________________________<o:p></o:p></p><p class=MsoPlainText>>> Bloat mailing list<o:p></o:p></p><p class=MsoPlainText>>> <a href="mailto:Bloat@lists.bufferbloat.net"><span style='color:windowtext;text-decoration:none'>Bloat@lists.bufferbloat.net</span></a><o:p></o:p></p><p class=MsoPlainText>>> <a href="https://lists.bufferbloat.net/listinfo/bloat"><span style='color:windowtext;text-decoration:none'>https://lists.bufferbloat.net/listinfo/bloat</span></a><o:p></o:p></p><p class=MsoPlainText>><o:p> </o:p></p><p class=MsoPlainText>>_______________________________________________<o:p></o:p></p><p class=MsoPlainText>>Bloat mailing list<o:p></o:p></p><p class=MsoPlainText>><a href="mailto:Bloat@lists.bufferbloat.net"><span style='color:windowtext;text-decoration:none'>Bloat@lists.bufferbloat.net</span></a><o:p></o:p></p><p class=MsoPlainText>><a href="https://lists.bufferbloat.net/listinfo/bloat"><span style='color:windowtext;text-decoration:none'>https://lists.bufferbloat.net/listinfo/bloat</span></a><o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p></div></body></html>