From: Paolo Valente <paolo.valente@unimore.it>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Detecting bufferbloat from outside a node
Date: Mon, 27 Apr 2015 12:53:15 +0200 [thread overview]
Message-ID: <08759E4A-AF05-4C28-AE99-A61F8524218A@unimore.it> (raw)
In-Reply-To: <87k2wx3m4k.fsf@toke.dk>
Il giorno 27/apr/2015, alle ore 12:23, Toke Høiland-Jørgensen <toke@toke.dk> ha scritto:
> Paolo Valente <paolo.valente@unimore.it> writes:
>
>> I am sorry, but I realized that what I said was incomplete. The main
>> cause of my concern is that, from outside the node, we do not know
>> whether a VoIP packet departs ad a given time because the application
>> wants it to be sent at that time or because it has waited in the
>> buffer for a lot of time. Similarly, we do not know how long the VoIP
>> application will wait before getting its incoming packets delivered.
>
> No, not unless the application tells you (by, for instance,
> timestamping; depending on where in the network stack the timestamp is
> applied, you can measure different instances of bloat).
That’s exactly what I was thinking about. Actually it seems the only solution to me.
What apparently makes things more difficult is that I am not allowed either to choose the applications to run or to interfere in any way with the flows (e.g., by injecting some extra packet).
Any pointer to previous/current work on this topic?
> Or if you know
> that an application is supposed to answer you immediately (as is the
> case with a regular 'ping'), you can measure if it does so even when
> otherwise loaded.
>
A ping was one of the first simple actions I suggested, but the answer was, as above: no you cannot ‘touch' the network!
> Of course, you also might not measure anything, if the bottleneck is
> elsewhere. But if you can control the conditions well enough, you can
> probably avoid this; just be aware of it. In Linux, combating
> bufferbloat has been quite the game of whack-a-mole over the last
> several years :)
>
Then I guess that now I am trying to build a good mallet according to the rules of the game for this company :)
In any case, the target networks should be observable at such a level that, yes, all relevant conditions should be under control (if one does not make mistakes). My problem is, as I wrote above, to find out what information I can and have to look at.
Thanks,
Paolo
> -Toke
--
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-04-27 10:53 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
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 [this message]
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=08759E4A-AF05-4C28-AE99-A61F8524218A@unimore.it \
--to=paolo.valente@unimore.it \
--cc=bloat@lists.bufferbloat.net \
--cc=toke@toke.dk \
/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