From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f98.google.com (mail-la0-f98.google.com [209.85.215.98]) (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 EBD4321F209 for ; Mon, 27 Apr 2015 13:31:04 -0700 (PDT) Received: by lamq1 with SMTP id q1so2494304lam.3 for ; Mon, 27 Apr 2015 13:31:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=lNh9w1ZJpdVPaiVSC1aH7b6fl9Ygyn1f7tuOflzxxP8=; b=cVbaulxQxUW82zVtAUdPrOGR4oKvDKjGn7n72WbC2yXWfYovaI53ZCYwDw7q1DYSpH Qgk6HfFqoCmDtLF7xy6HNnb4SojGbM92RJPD2Y4TiUgijGeBmwPF2x7/LSluRTtgpc/O 6t6gRr3tTcfxnIhxRmVxq4B81odYF425s5kTd6yipwMZECwmIhCZUOtdAm9kBARw1P19 b41BRDJt6OO9CxLvgMOi1BVp97v20rdOt4eG3Ac6IOD9ssIMw4g2347sYTGzS7PTgus2 cphnA6X1RvSwQhxdOh41cSApuu1W6Z4r9Wxuyv5wctfa9YbBcF/dG6IEJpUkU0VinJaM aB2A== X-Gm-Message-State: ALoCoQkul026NFjJ7VaHmmBLAquZwZLDS4mZYv0UKstyJZPGM3oz9KfE6r8qxbnfzcv2/HIZmi1s9GpXDSfBAuVVeNis0vE1vg== X-Received: by 10.194.171.1 with SMTP id aq1mr26247849wjc.38.1430166662650; Mon, 27 Apr 2015 13:31:02 -0700 (PDT) Received: from mail.la.pnsol.com (eu1sys200aog118.obsmtp.com. [207.126.144.145]) by mx.google.com with SMTPS id ew9sm414511wic.3.2015.04.27.13.31.01 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 27 Apr 2015 13:31:02 -0700 (PDT) X-Relaying-Domain: pnsol.com Received: from mail.la.pnsol.com ([89.145.213.110]) (using TLSv1) by eu1sys200aob118.postini.com ([207.126.147.11]) with SMTP ID DSNKVT6chPAVRVG26Qh0jCfen9LfjxGSj/2e@postini.com; Mon, 27 Apr 2015 20:31:01 UTC Received: from git.pnsol.com ([172.20.5.238] helo=roam.smtp.pnsol.com) by mail.la.pnsol.com with esmtp (Exim 4.76) (envelope-from ) id 1Ympg9-00032Z-1k; Mon, 27 Apr 2015 21:30:57 +0100 Received: from [172.20.5.109] by roam.smtp.pnsol.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Ympfy-0000AA-RB; Mon, 27 Apr 2015 20:30:46 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_3B4B3F48-AA62-48AE-8330-311888AF968E" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Neil Davies In-Reply-To: Date: Mon, 27 Apr 2015 21:30:59 +0100 Message-Id: <766042D4-0C90-4C77-9033-07B8E436C35B@pnsol.com> References: <72DB0260-F0DF-426F-A3F3-ECF5D8AF228F@pnsol.com> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) 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 20:31:33 -0000 --Apple-Mail=_3B4B3F48-AA62-48AE-8330-311888AF968E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. >=20 > 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. >=20 > - 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. 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 Neil= --Apple-Mail=_3B4B3F48-AA62-48AE-8330-311888AF968E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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. 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.

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

Neil
= --Apple-Mail=_3B4B3F48-AA62-48AE-8330-311888AF968E--