From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vn0-x236.google.com (mail-vn0-x236.google.com [IPv6:2607:f8b0:400c:c0f::236]) (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 3A49821F209 for ; Mon, 27 Apr 2015 16:11:31 -0700 (PDT) Received: by vnbg190 with SMTP id g190so14121201vnb.8 for ; Mon, 27 Apr 2015 16:11:30 -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=Y1n0gxQwC5KdMZXYo1+3w+/UqG+1REwCjCJ7vK0nrd8=; b=L8fhrjKB9z4PtPQ6Yr6S2vTCZK4yv20y+77Cj70Izyjg1l1o3EouaA7AowqWLJco/0 UWHGKbuqzs7EmT8sioIN/32bmPsRgUAvwWyPCca4qhezCWdOo0MjijjOVWL64M2UhJiM mj4yWLppMaDEUm7jfneGJjfGhH2n5fjB7+40+AP1qMltAMY7YEVMDFVDerEhMY5SyKrD KVGVus9Qq8w8z1SVtAICBqs569LxrCr1SYPd9Jtul4WTnIjoySEMNTPfrV05ViXIBuK2 lJlNLmGBdNmQ5QmFKuZ8NdsyGrKk7ksKmNSdMFVqR6LaFx0BcUrf9i9QX4atW3aMO/qX C9lg== MIME-Version: 1.0 X-Received: by 10.52.112.7 with SMTP id im7mr31370784vdb.95.1430176290913; Mon, 27 Apr 2015 16:11:30 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Mon, 27 Apr 2015 16:11:30 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Mon, 27 Apr 2015 16:11:30 -0700 (PDT) In-Reply-To: <766042D4-0C90-4C77-9033-07B8E436C35B@pnsol.com> References: <72DB0260-F0DF-426F-A3F3-ECF5D8AF228F@pnsol.com> <766042D4-0C90-4C77-9033-07B8E436C35B@pnsol.com> Date: Tue, 28 Apr 2015 02:11:30 +0300 Message-ID: From: Jonathan Morton To: Neil Davies Content-Type: multipart/alternative; boundary=bcaec548a6abc942fe0514bcdddb Cc: bloat Subject: Re: [Bloat] Detecting bufferbloat from outside a node 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: Mon, 27 Apr 2015 23:12:00 -0000 --bcaec548a6abc942fe0514bcdddb Content-Type: text/plain; charset=UTF-8 On 27 Apr 2015 23:31, "Neil Davies" wrote: > > Hi Jonathan > > On 27 Apr 2015, at 16:25, Jonathan Morton wrote: > >> One thing that might help you here is the TCP Timestamps option. The timestamps thus produced are opaque, but you can observe them and measure the time intervals between their production and echo. You should be able to infer something from that, with care. >> >> To determine the difference between loaded and unloaded states, you may need to observe for an extended period of time. Eventually you'll observe some sort of bulk flow, even if it's just a software update cycle. It's not quite so certain that you'll observe an idle state, but it is sufficient to observe an instance of the link not being completely saturated, which is likely to occur at least occasionally. >> >> - Jonathan Morton > > We looked at using TCP timestamps early on in our work. The problem is that they don't really help extract the fine-grained information needed. The timestamps can move in very large steps, and the accuracy (and precision) can vary widely from implementation to implementation. Well, that's why you have to treat them as opaque, just like I said. Ignore whatever meaning the end host producing them might embed in them, and simply watch which ones get echoed back and when. You only have to rely on the resolution of your own clocks. > The timestamps are there to try and get a gross (if my memory serves me right ~100ms) approximation to the RTT - not good enough for reasoning about TCP based interactive/"real time" apps On the contrary, these timestamps can indicate much better precision than that; in particular they indicate an upper bound on the instantaneous RTT which can be quite tight under favourable circumstances. On a LAN, you could reliably determine that the RTT was below 1ms this way. Now, what it doesn't give you is a strict lower bound. But you can often look at what's going on in that TCP stream and determine that favourable circumstances exist, such that the upper bound RTT estimate is probably reasonably tight. Or you could observe that the stream is mostly idle, and thus probably influenced by delayed acks and Nagle's algorithm, and discount that measurement accordingly. - Jonathan Morton --bcaec548a6abc942fe0514bcdddb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 27 Apr 2015 23:31, "Neil Davies" <neil.davies@pnsol.com> wrote:
>
> Hi Jonathan
>
> On 27 Apr 2015, at 16:25, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> One thing that might help you here is the TCP Timestamps option. T= he timestamps thus produced are opaque, but you can observe them and measur= e the time intervals between their production and echo. You should be able = to infer something from that, with care.
>>
>> To determine the difference between loaded and unloaded states, yo= u may need to observe for an extended period of time. Eventually you'll= observe some sort of bulk flow, even if it's just a software update cy= cle. It's not quite so certain that you'll observe an idle state, b= ut it is sufficient to observe an instance of the link not being completely= saturated, which is likely to occur at least occasionally.
>>
>> - Jonathan Morton
>
> We looked at using TCP timestamps early on in our work. The problem is= that they don't really help extract the fine-grained information neede= d. The timestamps can move in very large steps, and the accuracy (and preci= sion) can vary widely from implementation to implementation.

Well, that's why you have to treat them as opaque, just = like I said. Ignore whatever meaning the end host producing them might embe= d in them, and simply watch which ones get echoed back and when. You only h= ave to rely on the resolution of your own clocks.

> The timestamps are there to try and get a gross (if my = memory serves me right ~100ms) approximation to the RTT - not good enough f= or reasoning about TCP based interactive/"real time" apps

On the contrary, these timestamps can indicate much better p= recision than that; in particular they indicate an upper bound on the insta= ntaneous RTT which can be quite tight under favourable circumstances. On a = LAN, you could reliably determine that the RTT was below 1ms this way.

Now, what it doesn't give you is a strict lower bound. B= ut you can often look at what's going on in that TCP stream and determi= ne that favourable circumstances exist, such that the upper bound RTT estim= ate is probably reasonably tight. Or you could observe that the stream is m= ostly idle, and thus probably influenced by delayed acks and Nagle's al= gorithm, and discount that measurement accordingly.

- Jonathan Morton

--bcaec548a6abc942fe0514bcdddb--