From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7D20A21F5BE for ; Sat, 23 Aug 2014 13:01:43 -0700 (PDT) Received: from hms-beagle.home.lan ([217.86.104.125]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Ldttv-1Wdvzl1pWV-00iyDf; Sat, 23 Aug 2014 22:01:39 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <000001cfbefe$69194c70$3b4be550$@duckware.com> Date: Sat, 23 Aug 2014 22:01:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000001cfbefe$69194c70$3b4be550$@duckware.com> To: Jerry Jongerius X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:hrtcr1/L+gq8kNWovgv79CRVL2J13fksSyfk18XGNQdKWnOy03b 7kaTf06NOyNX9sjnIuPfJZ91B4fES4mO6gmvRAaPmh+NrJb4YdeeUotiYsQmdtwp9kFAMyy pCoHb1PvDY+6AW2SzSe8sitYmy/VC09cB8aQLkjcjtqvTvtcFXlDHCWLkmrMv8sP4bDjc4t nZIrB3B4ZRfdABsbymd0g== X-UI-Out-Filterresults: notjunk:1; Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] The Dark Problem with AQM in the Internet? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 20:01:44 -0000 Hi Jerry, On Aug 23, 2014, at 20:16 , Jerry Jongerius wrote: > Request for comments on: www.duckware.com/darkaqm >=20 > The bottom line: How do you know which AQM device in a network = intentionally > drops a packet, without cooperation from AQM? >=20 > 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=92s 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.)=20 Also, I believe, a congested router is going to drop packets to = be able to =93survive=94 the current load, it is not going to send = additional packets to inform you that it is overloaded... =09 Best Regards Sebastian >=20 >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat