From: Neil Davies <neil.davies@pnsol.com>
To: Paolo Valente <paolo.valente@unimore.it>
Cc: Jonathan Morton <chromatix99@gmail.com>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Detecting bufferbloat from outside a node
Date: Mon, 4 May 2015 11:44:34 +0100 [thread overview]
Message-ID: <57FECE9A-B4FB-4216-A081-A78B5489A237@pnsol.com> (raw)
In-Reply-To: <C7EF9B32-1685-4341-966D-14336E6C7A03@unimore.it>
On 4 May 2015, at 11:41, Paolo Valente <paolo.valente@unimore.it> wrote:
> Thanks for this extra information and suggestions. Just to be certain that I am not missing anything: I am assuming that also the observed delay you mention is the delay observed from outside endpoints, and not the total delay that one would obtain by adding also the queueing delays inside end points (which, in my case, is one of the unobservable quantities).
Paolo, this is where the difference between ∆Q|G, ∆Q|S and ∆Q|V are important - the extraction of the ∆Q|G and ∆Q|S establishes the structural delay, differences from that structural delay are caused by the contention for the onward transmission resources.
> Il giorno 04/mag/2015, alle ore 12:28, Jonathan Morton <chromatix99@gmail.com> ha scritto:
>
>> Generally, the minimum observed delay will correspond to the case when both inbound and outbound queues are empty throughout the path. This delay should correspond to basic propagation and forwarding delays, which can't be reduced further without altering some aspect of the network.
>>
>> Higher observed delays than this will tend to correspond to one or both of the buffers at the bottleneck being persistently filled. To work out which one, you'll need to estimate the network load in each direction. This is of course easiest if you can see all or most of the traffic passing the bottleneck link, or if you yourself are participating in that load, but it's probably possible in some other situations if you get creative.
>>
>> To determine that bloat is NOT present, you need to observe delays that are close to the baseline unloaded condition, while also being fairly sure that the bottleneck link is saturated in the relevant direction.
>>
>> The most reliable indication of link saturation is to observe ECN marked packets, which will only normally be produced by an AQM algorithm signalling link congestion (where both endpoints of the flow have negotiated ECN support). A slightly less reliable indication of saturation is to observe lost packets, either via retransmission or ack patterns, especially if they occur in bursts or at remarkably regular intervals.
>>
>> - Jonathan Morton
>
>
> --
> Paolo Valente
> Algogroup
> Dipartimento di Fisica, Informatica e Matematica
> Via Campi, 213/B
> 41125 Modena - Italy
> homepage: http://algogroup.unimore.it/people/paolo/
>
next prev parent reply other threads:[~2015-05-04 10:44 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
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 [this message]
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=57FECE9A-B4FB-4216-A081-A78B5489A237@pnsol.com \
--to=neil.davies@pnsol.com \
--cc=bloat@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=paolo.valente@unimore.it \
/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