Re: [Bloat] The Dark Problem with AQM in the Internet?

["Jerry Jongerius" <jerryj@duckware.com>]

[-- Attachment #1: Type: text/plain, Size: 7239 bytes --]

Mr. White,

 

AQM is 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 you going to
do that?  Or how do you propose to do that?

 

The graph presented is caused the interaction of a single dropped packet,
bufferbloat, and the Westwood+ congestion control algorithm – and not power
boost.

 

- Jerry

 

 

 

-----Original Message-----
From: Greg White [mailto:g.white@CableLabs.com] 
Sent: Monday, August 25, 2014 1:14 PM
To: Sebastian Moeller; Jerry Jongerius
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] The Dark Problem with AQM in the Internet?

 

As far as I know there are no deployments of AQM in DOCSIS networks yet.

So, the effect you are seeing is unlikely to be due to AQM.

 

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.

 

I ran a quick simulation of a simple network with power boost and basic

(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.

 

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.

 

-Greg

 

On 8/23/14, 2:01 PM, "Sebastian Moeller" < <mailto:moeller0@gmx.de>
moeller0@gmx.de> wrote:

 

>Hi Jerry,

> 

>On Aug 23, 2014, at 20:16 , Jerry Jongerius < <mailto:jerryj@duckware.com>
jerryj@duckware.com> wrote:

> 

>> Request for comments on:  <http://www.duckware.com/darkaqm>
www.duckware.com/darkaqm

>> 

>> The bottom line: How do you know which AQM device in a network 

>>intentionally  drops a packet, without cooperation from AQM?

>> 

>> Or is this in AQM somewhere and I just missed it?

> 

> 

>I am sure you will get more expert responses later, but let me try to 

>comment.

> 

>Paragraph 1:

> 

>I think you hit the nail on the head with your observation:

> 

>The average user can not figure out what AQM device intentionally 

>dropped packets

> 

>Only, I might add, this does not depend on AQM, the user can not figure 

>out where packets where dropped in the case that not all involved 

>network hops are under said user¹s control ;) So move on, nothing to 

>see here ;)

> 

>Paragraph 2:

> 

>There is no guarantee that any network equipment responds to ICMP 

>requests at all (for example my DSLAM does not). What about pinging a 

>host further away and look at that hosts RTT development over time?

>(Minor clarification: its the load dependent increase of ping RTT to 

>the CMTS that would be diagnostic of a queue, not the RTT per se). No 

>increase of ICMP RTT could also mean there is no AQM involved ;)

> 

>             I used to think along similar lines, but reading 

> <https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Tracero>
https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Tracero

>ute _N47_Sun.pdf made me realize that my assumptions about ping and 

>trace route were not really backed up by reality. Notably traceroute 

>will not necessarily show the real data's path and latencies or drop 

>probability.

> 

>Paragraph 3

> 

>What is the advertised bandwidth of your link? To my naive eye this 

>looks a bit like power boosting (the cable company allowing you higher 

>than advertised bandwidth for a short time that is later reduced to the 

>advertised speed). Your plot needs a better legend, BTW, what is the 

>blue line showing? When you say that neither ping nor trace route 

>showed anything, I assumed that you measured concurrently to your 

>download. It would be really great if you could netperf-wrapper to get 

>comparable data (see the link on 

> <http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferb>
http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferb

>loa t ) There the latency is not only assessed by ICMP echo requests 

>but also by UDP packets, and it is very unlikely that your ISP can 

>special case these in any tricky way, short of giving priority to 

>sparse flows (which is pretty much what you would like your ISP to do 

>in the first place ;) )

> 

>             Here is where I reveal that I am just a layman, but you
complain about 

>the loss of one packet, but how do you assume does a (TCP) settle on 

>its transfer speed? Exactly it keeps increasing until it looses a 

>packet, then reduces its speed to 50% or so and slowly ramps up again 

>until the next packet loss. So unless your test data is not TCP I see 

>no way to avoid packet loss (and no reason why it is harmful). Now if 

>my power boost intuition should prove right I can explain the massive 

>drop quite well, TCP had ramped up to above the long-term stable and 

>suffers several packet losses in a short time, basically resetting it 

>to 0 or so, therefore the new ramping to 40Mbps looks pretty similar to 

>the initial ramping to 110Mbps...

> 

>Paragraph 4:

> 

>I guess, ECN, explicit congestion notification is the best you can 

>expect, or routers will initially set a mark on a packet to notify the 

>TCP endpoints that they need to throttle the speed unless that want to 

>risk packet loss. But not all routers are configured to use it (plus 

>you need to configure your endpoints correctly, see:

> <http://www.bufferbloat.net/projects/cerowrt/wiki/Enable_ECN>
http://www.bufferbloat.net/projects/cerowrt/wiki/Enable_ECN ). But this 

>will not tell you where along the path congestion occurred, only that 

>it occurred (and if push comes to shove your packets still get dropped.)

>             Also, I believe, a congested router is going to drop packets
to be 

>able to ³survive² the current load, it is not going to send additional 

>packets to inform you that it is overloaded...

>             

> 

>Best Regards

>             Sebastian

> 

> 

>> 

>> 

>> _______________________________________________

>> Bloat mailing list

>>  <mailto:Bloat@lists.bufferbloat.net> Bloat@lists.bufferbloat.net

>>  <https://lists.bufferbloat.net/listinfo/bloat>
https://lists.bufferbloat.net/listinfo/bloat

> 

>_______________________________________________

>Bloat mailing list

> <mailto:Bloat@lists.bufferbloat.net> Bloat@lists.bufferbloat.net

> <https://lists.bufferbloat.net/listinfo/bloat>
https://lists.bufferbloat.net/listinfo/bloat

 


[-- Attachment #2: Type: text/html, Size: 16559 bytes --]