From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "alln-iport.cisco.com", Issuer "HydrantID SSL ICA G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id B5EC321F852 for ; Thu, 30 Jul 2015 06:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2148; q=dns/txt; s=iport; t=1438261497; x=1439471097; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dsNt/fB+lgkIEk1t3kuu7VPMK11Ishd5f6UZh6H00qw=; b=k9Ulxxk46aLjLOv5WwlJEjgp6ibkAX/i9v84dYcrkR9j865FaTIN+2lk 3Sz1UA/GJ7yMoQUiNycw/9Hk1dbwJxi3ZNvZqhvd6al/vTnzmbctkptXr Go4mvuGPW+A+F+CAjHqHujmu+NWL2u+JVieFrIrPr8HDYFgCn0j27XSTj 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ABBQCbH7pV/5xdJa1VBoMaVGkGvByBeQqFeQKBNzoSAQEBAQEBAYEKhCMBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQcnAQoUCQgCBAENBQiIJg3OZgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi06EPAgSMQcGgxKBFAWHFYZghwIBhHqEcYQklA6DZCaDfW+BSIEEAQEB X-IronPort-AV: E=Sophos;i="5.15,577,1432598400"; d="scan'208";a="173670993" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP; 30 Jul 2015 13:04:21 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t6UD4LhZ019947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jul 2015 13:04:21 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.100]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Thu, 30 Jul 2015 08:04:09 -0500 From: "Bill Ver Steeg (versteb)" To: Jan Ceuleers , Mikael Abrahamsson , David Lang Thread-Topic: [Bloat] Speed tests - attribution of latency to relevant network hops Thread-Index: AQHQykWIw5ayLuUtGE+Xp1bS3nNtOp3zxnqAgAAG8YCAACzKMA== Date: Thu, 30 Jul 2015 13:04:08 +0000 Message-ID: References: <55B92BF3.2000607@gmail.com> <55B9B37B.9050506@gmail.com> In-Reply-To: <55B9B37B.9050506@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.100.113.237] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 13:04:58 -0000 You do have to be careful using ttl tricks and/or ICMP packets for fine-gra= ined 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 pack= ets and in the slow path for unusual packets.=20 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 h= andle the timing differences when the slow path was MUCH slower than the fa= st path and it distorted the results. You would also have to handle some we= ird edge conditions..... The worst case that springs to mind would be a blo= ated buffer somewhere in a device's fast path (due to lots of "normal" pack= ets), but the slow path on the same device is not congested and thus actual= ly has less delay for this single packet. Bvs =20 -----Original Message----- From: bloat-bounces@lists.bufferbloat.net [mailto:bloat-bounces@lists.buffe= rbloat.net] On Behalf Of Jan Ceuleers Sent: Thursday, July 30, 2015 1:18 AM To: Mikael Abrahamsson; David Lang Cc: bloat Subject: Re: [Bloat] Speed tests - attribution of latency to relevant netwo= rk hops On 30/07/15 06:52, Mikael Abrahamsson wrote: > On Wed, 29 Jul 2015, David Lang wrote: >=20 >> unless you measure it per hop, how are you going to attribute it to=20 >> each hop? and unless you have a server at that layer to talk to, how=20 >> do you know what the latency or bandwidth is? >=20 > Measuring latency is doable (using the same mechanism that traceroute=20 > with for instance max-ttl 5), but I don't know how much of this is=20 > available to your web application? >=20 > If you sent 5 packets with TTL 1-5 and measured the time to get back=20 > the ttl-expired-in-transit ICMP, you could get an indication where the=20 > latency increase was happening. Yes, that's what I had in mind. _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat