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

[Sebastian Moeller <moeller0@gmx.de>]

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_Bufferbloat ) 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