From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 224C121F1F7 for ; Tue, 28 Apr 2015 02:58:42 -0700 (PDT) Received: from hms-beagle.lan ([134.2.89.70]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MWCKz-1YotpG18p7-00XKBs; Tue, 28 Apr 2015 11:58:39 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Tue, 28 Apr 2015 11:58:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <72DB0260-F0DF-426F-A3F3-ECF5D8AF228F@pnsol.com> <766042D4-0C90-4C77-9033-07B8E436C35B@pnsol.com> To: Neil Davies X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:2Mp4ygvbH1fR4AYQavfwBP0whvoQyhA1kmn0M9be5I/41lU9OuR n/jBeQe5QspMeQvmDvAP/C1zIRImmwisvrxRcdGTyW8Be+LpX91NGlOQ7M2Pqtviy7MLN4k S5vr96oFafTCp8klH9b7iUE+yhYC6dtoGmrwYWGTEwbOWfbs0LqfuQFRLsxfoovogEoDbXi i14WBGjD3tw0qmYpujX8g== X-UI-Out-Filterresults: notjunk:1; Cc: Jonathan Morton , 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: Tue, 28 Apr 2015 09:59:11 -0000 Hi Neil, On Apr 28, 2015, at 09:17 , Neil Davies wrote: > Jonathan >=20 > The timestamps don't change very quickly - dozens (or more) of packets = can have the same timestamp, so it doesn't give you the appropriate = discrimination power. Timed observations at key points gives you all you = need (actually, appropriately gathered they give you all you can = possibly know - by observation) But this has two issues: 1) =93timed observations=94: relatively easy if all nodes are under your = control otherwise hard. I know about the CERN paper, but they had all = nodes under their control, symmetric bandwidth and shipload of samples, = so over the wild internet =93timed observations=94 are still hard (and = harder as the temporal precision requirement goes up) 2) =93key points=94: once you know the key points you already must have = a decent understanding on the effective topology of the network, which = again over the wider internet is much harder than if one has all nodes = under control. I am not sure how Paolo=92s =93no-touching=94 problem fits into the = requirements for your deltaQ (meta-)math ;) Best Regards Sebastian >=20 > Neil >=20 > On 28 Apr 2015, at 00:11, Jonathan Morton = wrote: >=20 >> 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. >>=20 >> 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. >>=20 >> > 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 >>=20 >> 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. >>=20 >> 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. >>=20 >> - Jonathan Morton >>=20 >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat