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

[Greg White <g.white@CableLabs.com>]

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

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" <moeller0@gmx.de> wrote:

>Hi Jerry,
>
>On Aug 23, 2014, at 20:16 , Jerry Jongerius <jerryj@duckware.com> wrote:
>
>> Request for comments on: 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_Traceroute
>_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_Bufferbloa
>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 ). 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
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>
>_______________________________________________
>Bloat mailing list
>Bloat@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/bloat


[-- Attachment #2: thruput.pdf --]
[-- Type: application/pdf, Size: 25625 bytes --]