From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay109.isp.belgacom.be (mailrelay109.isp.belgacom.be [195.238.20.136]) by huchra.bufferbloat.net (Postfix) with ESMTP id D655621F27F for ; Thu, 30 Jul 2015 07:57:03 -0700 (PDT) X-Belgacom-Dynamic: yes X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=Cjxj77ls1R2S+e9aJ2LrqpY3XlZy0HpxyZbjmPPvmIM= c=1 sm=2 a=LpDB9HmdtQohtvk9wecA:9 a=pILNOxqGKmIA:10 a=FLBaegxm5dBZchIm:21 a=XocXTggMW9IL_I0q:21 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CBDADUOrpV/6Re9FFVBoMaskaQQIJWAoE4PRABAQEBAQEBgQqEIwEBAQMBVgYcAQULCwsHBgkWDwkDAgECAREWEA4GAQwBBwEBiBQBDQwBum+OGQoZgQuEWAEBAQEBAQEDAQEBAQEBARuLToREQweELAEElHeMSYhYkGEmg388gn0BAQE Received: from 164.94-244-81.adsl-dyn.isp.belgacom.be (HELO zotac.xperim.be) ([81.244.94.164]) by relay.skynet.be with ESMTP; 30 Jul 2015 16:57:01 +0200 Received: from [192.168.1.172] (mordor.xperim.be [192.168.1.172]) by zotac.xperim.be (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id t6UEsr4I005495; Thu, 30 Jul 2015 16:54:53 +0200 Message-ID: <55BA3ABD.2010902@gmail.com> Date: Thu, 30 Jul 2015 16:54:53 +0200 From: Jan Ceuleers User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "Bill Ver Steeg (versteb)" , Mikael Abrahamsson , David Lang References: <55B92BF3.2000607@gmail.com> <55B9B37B.9050506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: bloat Subject: Re: [Bloat] Speed tests - attribution of latency to relevant network hops 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: Thu, 30 Jul 2015 14:57:32 -0000 On 30/07/15 15:04, Bill Ver Steeg (versteb) wrote: > You do have to be careful using ttl tricks and/or ICMP packets for fine-grained timing measurements. On many middleboxes, there is a "fast path" that is done in a highly optimized manner (often in silicon) and a "slow path". In a non-zero number of cases, you will be in the fast path for normal packets and in the slow path for unusual packets. Yes, understood and agreed. But I think it would already be very enlightening to lots of users (and also assist the "make wifi faster" efforts) to understand how much of the bloat sits in the part of the network that they can fix themselves, how much of it they can hold their service provided accountable for and how much of it they essentially have to put up with because it's inherent to the way they're plumbed into the interweb. So perhaps it's not possible to break the dslreports bloat graphs down into the three segments that I described, because all we have available is ICMP and the TTL field, but even a graphical representation of a traceroute-while-idle and a traceroute-under-load would be a step forward. > What you describe will work for the vast majority of cases, but there will be situations in which you will get misleading results. You would need to handle the timing differences when the slow path was MUCH slower than the fast path and it distorted the results. You would also have to handle some weird edge conditions..... The worst case that springs to mind would be a bloated buffer somewhere in a device's fast path (due to lots of "normal" packets), but the slow path on the same device is not congested and thus actually has less delay for this single packet. My first thought was that I'd expect that the fast path queues in which packets might spend a non-negligible amount of time would sit on the egress side of the box rather than on the ingress side, and that it is only the ingress queue that would affect both fast-path and slow-path traffic. But I guess that this depends heavily on the architecture of the box, so you're probably right. Jan