General list for discussing Bufferbloat
 help / color / mirror / Atom feed
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/


  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