From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3447121F42B for ; Thu, 30 Jul 2015 08:27:13 -0700 (PDT) Received: by oigi136 with SMTP id i136so23609855oig.1 for ; Thu, 30 Jul 2015 08:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QEXkVjrNf49fy4m3Dmk3cEqk7ds4TpEPWgDo5xN3/CQ=; b=ChUHBvHh+DDv/tt46UqTV1kf7ilFPaqpJ67pEB3o+w8kPt2t4sT4Mlmp5zdLkOVDCB Q4nCOuMhCojfRouQH7bHmMHEwJf7n/NuOW5MbxFy0G6Cf3tB2TDKRcIPcDK650gwtCJT UpAp2J8JtSlj4Q5q9YIvtumqJHTiLEf0/Zy3yrkAcGHJXo8qJ6dGV1GGKexXJWSi/Ctv O9N7UzEKa8u8yagMVDGWu8ZVJLeMfFWnf9DnqX5K0uital5K6VTzbgyTsJfCaM3CAKLV 43l7jBSn8Eg6eJ+IixfqXqo4VszYtY7L/7V8VQYshCJEfKBONbT24ZCpHVx4DwYxftZf hs6g== MIME-Version: 1.0 X-Received: by 10.202.129.70 with SMTP id c67mr44984695oid.42.1438270032905; Thu, 30 Jul 2015 08:27:12 -0700 (PDT) Received: by 10.202.73.2 with HTTP; Thu, 30 Jul 2015 08:27:12 -0700 (PDT) In-Reply-To: <55BA3ABD.2010902@gmail.com> References: <55B92BF3.2000607@gmail.com> <55B9B37B.9050506@gmail.com> <55BA3ABD.2010902@gmail.com> Date: Thu, 30 Jul 2015 17:27:12 +0200 Message-ID: From: Dave Taht To: Jan Ceuleers Content-Type: text/plain; charset=UTF-8 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 15:27:42 -0000 The tool for looking at this is called "mtr", which is available in various forms for linux, osx, and windows. It was originally part of the rrul spec, but parsing it's output is a little difficult (or was - there is csv support for it now in linux mainline), and the biggest reason left (besides lack of time to implement it - patches gladly accepted!) we don't use it yet is that it imparts enough traffic to measurably jigger the other results at lower bandwidths. Certainly, instead of blending together the outputs of multiple separate tools as we currently do with flent, it would be better to have one specific tool that measured everything we care about all at the same time and (for example) saw, rather than estimated, acks - but that requires a scale of development effort and funding that we have never had. I do have hope that one day webrtc could be leveraged to give us udp measurements from within a browser. The current dslreports ping over tcp method is subject to a multiplicity of problems. I would not mind at all if browsers gained the ability to set the ttl, also.