General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Neil Davies <neil.davies@pnsol.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Detecting bufferbloat from outside a node
Date: Tue, 28 Apr 2015 02:11:30 +0300	[thread overview]
Message-ID: <CAJq5cE1wUanDqz9jboSHS1SqQ2b-T3OQ_yPgGbEMDO1eNVqurQ@mail.gmail.com> (raw)
In-Reply-To: <766042D4-0C90-4C77-9033-07B8E436C35B@pnsol.com>

[-- Attachment #1: Type: text/plain, Size: 2293 bytes --]

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. 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

[-- Attachment #2: Type: text/html, Size: 2665 bytes --]

  reply	other threads:[~2015-04-27 23:11 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-27  9:48 Paolo Valente
2015-04-27  9:54 ` Neil Davies
2015-04-27 10:45   ` Toke Høiland-Jørgensen
2015-04-27 10:57     ` Neil Davies
2015-04-27 14:22       ` Toke Høiland-Jørgensen
2015-04-27 20:27         ` Neil Davies
2015-04-27 15:51       ` Toke Høiland-Jørgensen
2015-04-27 20:38         ` Neil Davies
2015-04-27 21:37           ` Toke Høiland-Jørgensen
2015-04-28  7:14             ` Neil Davies
2015-04-27 11:54   ` Paolo Valente
2015-04-27 15:25     ` Jonathan Morton
2015-04-27 20:30       ` Neil Davies
2015-04-27 23:11         ` Jonathan Morton [this message]
2015-04-28  7:17           ` Neil Davies
2015-04-28  9:58             ` Sebastian Moeller
2015-04-28 10:23               ` Neil Davies
2015-05-04 10:10                 ` Paolo Valente
2015-05-04 10:21                   ` Neil Davies
2015-05-04 10:28                   ` Jonathan Morton
2015-05-04 10:41                     ` Paolo Valente
2015-05-04 10:44                       ` Neil Davies
2015-05-04 10:42                     ` Neil Davies
2015-05-04 11:33                       ` Jonathan Morton
2015-05-04 11:39                         ` Neil Davies
2015-05-04 12:17                           ` Jonathan Morton
2015-05-04 12:35                             ` Neil Davies
2015-05-04 17:39                               ` David Lang
2015-05-04 19:09                                 ` Jonathan Morton
2015-04-28 16:05             ` Rick Jones
2015-04-27 20:13     ` Neil Davies
2015-04-27  9:57 ` Toke Høiland-Jørgensen
2015-04-27 10:10   ` Paolo Valente
2015-04-27 10:19     ` Paolo Valente
2015-04-27 10:23       ` Toke Høiland-Jørgensen
2015-04-27 10:53         ` Paolo Valente
2015-04-27 20:39           ` David Lang
2015-05-04 10:31             ` Paolo Valente
2015-04-27 10:26       ` Neil Davies
2015-04-27 10:32         ` Toke Høiland-Jørgensen
2015-04-27 10:38           ` Neil Davies
2015-04-27 10:52             ` Toke Høiland-Jørgensen
2015-04-27 11:03               ` Neil Davies
2015-04-27 12:03                 ` Toke Høiland-Jørgensen
2015-04-27 20:19                   ` Neil Davies
2015-05-19 21:23                   ` Alan Jenkins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJq5cE1wUanDqz9jboSHS1SqQ2b-T3OQ_yPgGbEMDO1eNVqurQ@mail.gmail.com \
    --to=chromatix99@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=neil.davies@pnsol.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox