From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f98.google.com (mail-la0-f98.google.com [209.85.215.98]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 16AC721F23A for ; Mon, 27 Apr 2015 03:25:30 -0700 (PDT) Received: by labgd6 with SMTP id gd6so2167217lab.2 for ; Mon, 27 Apr 2015 03:25:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=BKC/0G4Mj/JKlcP6J6HY1tSTFK0iANxpRhVBBXYKklA=; b=FF/1BAyrIJ35YYpwtRvv0FYkt++g7OAw/EfCs/8+qtcrt4BTjUc1T+r1heXBpo5k+J 4XEIfAsx/CrGrJ2YzdIUfk/I9ua8s0b6SYsVkxbnC4kgXvRL5gzx5etEOgs38USiEQDw EcEgi+ZBel7BzrTgnJOmqeyZmOsn5PicrtKFry0E+ZFBNSyRWY/gLNKwpBbFNkb9+2P9 l1byTgnxeFY8dyFQltR2JePezlm5fpDh2xm5gLd0844b0QdyDziCH+dQCgokZQ2gYE2i 0181QqSZ3xO5hACw8zBawZBIdwv80MLXGhXa1Y7ZLXCyqNZNbez/fet/SFOrdibbFddp Yqxw== X-Gm-Message-State: ALoCoQlsTjpGIU6sz9UZDo3qeSpptQGokyncdJUPqo11GRvEzXdsrV/+ld5aDR3OUx+07aYJV/WBJWbVLunXazwo0Jj64rtwsw== X-Received: by 10.180.83.229 with SMTP id t5mr19637680wiy.82.1430130328766; Mon, 27 Apr 2015 03:25:28 -0700 (PDT) Received: from mail.la.pnsol.com (eu1sys200aog101.obsmtp.com. [207.126.144.111]) by mx.google.com with SMTPS id k6sm336824wiz.4.2015.04.27.03.25.27 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 27 Apr 2015 03:25:28 -0700 (PDT) X-Relaying-Domain: pnsol.com Received: from mail.la.pnsol.com ([89.145.213.110]) (using TLSv1) by eu1sys200aob101.postini.com ([207.126.147.11]) with SMTP ID DSNKVT4OlaSNzJpH+2gGr3aNDOb6DzwLZDZ8@postini.com; Mon, 27 Apr 2015 10:25:27 UTC Received: from ba6-office.pnsol.com ([172.20.5.199]) by mail.la.pnsol.com with esmtp (Exim 4.76) (envelope-from ) id 1YmgE5-0001PI-IZ; Mon, 27 Apr 2015 11:25:21 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_E0165EF1-C17D-491F-AED8-9BB9EB1BD625" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Neil Davies In-Reply-To: <3DC1A2EA-6DDD-4FF9-AD12-BB509EFB96B8@unimore.it> Date: Mon, 27 Apr 2015 11:26:16 +0100 Message-Id: <30560030-8A86-481D-A310-B3B72C26C368@pnsol.com> References: <87r3r53ncb.fsf@toke.dk> <04A0C729-6E87-49C6-84F7-3428F236CA15@unimore.it> <3DC1A2EA-6DDD-4FF9-AD12-BB509EFB96B8@unimore.it> To: Paolo Valente X-Mailer: Apple Mail (2.1878.6) Cc: 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: Mon, 27 Apr 2015 10:25:59 -0000 --Apple-Mail=_E0165EF1-C17D-491F-AED8-9BB9EB1BD625 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Paolo You are asking about the epistemology! Good start. The only things you = can =93know=94 outside the node are the things you can observe. You can = infer, from the characteristics of the observations, conformance to some = avowed model of behaviour. Welcome to the world operational, denotational and intentional semantics = as it relates to network performance! Neil On 27 Apr 2015, at 11:19, Paolo Valente = wrote: >=20 > Il giorno 27/apr/2015, alle ore 12:10, Paolo Valente = ha scritto: >=20 >>=20 >> Il giorno 27/apr/2015, alle ore 11:57, Toke H=F8iland-J=F8rgensen = ha scritto: >>=20 >>> Paolo Valente writes: >>>=20 >>>> a network-monitoring company got curious about bufferbloat issues = and >>>> asked me to investigate a little bit the following issue (quite >>>> interesting in my opinion). Is it possible to detect, from outside = a >>>> node, if the node is bufferbloated? In particular, the only action >>>> allowed would be to observe the packets entering and leaving the = node >>>> (plus, of course, their timing). >>>=20 >>> Sure. Just measure the timing when the network is unloaded and = compare >>> it to when it is loaded to capacity. We do that all the time. >>>=20 >>> The details of course depend on what you define by a 'node', what = role >>> it plays in the network (does it forward or originate packets?), and >>> what control you have over the traffic flowing through it. :) >>>=20 >>=20 >> Let us consider, for example, a host with a VoIP call and a = large-file transfer in progress. My concern is: from inside the host, we = can measure the delays experienced by the VoIP application, but, form = outside, how can we detect that the application is experiencing a high = latency, or, indirectly, that there is bufferbloat and hence that the = application is likely to be experiencing a high latency? (Of course, I = am also about to read the documents suggested by Neil.) >>=20 >=20 > 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. >=20 > Of course, if a bufferbloated state can be measured by other external = measurements, then we can infer the problem indirectly. >=20 > Are there flaws in my above considerations? >=20 > Thanks, > Paolo >=20 >> Thanks, >> Paolo >>=20 >>> -Toke >>=20 >>=20 >> -- >> Paolo Valente =20 >> Algogroup >> Dipartimento di Fisica, Informatica e Matematica =09 >> Via Campi, 213/B >> 41125 Modena - Italy =20 >> homepage: http://algogroup.unimore.it/people/paolo/ >=20 >=20 > -- > Paolo Valente =20 > Algogroup > Dipartimento di Fisica, Informatica e Matematica =09 > Via Campi, 213/B > 41125 Modena - Italy =20 > homepage: http://algogroup.unimore.it/people/paolo/ >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --Apple-Mail=_E0165EF1-C17D-491F-AED8-9BB9EB1BD625 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Paolo

You are asking about the = epistemology! Good start. The only things you can =93know=94 outside the = node are the things you can observe. You can infer, from the = characteristics of the observations, conformance to some avowed model of = behaviour.

Welcome to the world operational, = denotational and intentional semantics as it relates to network = performance!

Neil

On 27 = Apr 2015, at 11:19, Paolo Valente <paolo.valente@unimore.it> = wrote:


Il giorno 27/apr/2015, alle = ore 12:10, Paolo Valente <paolo.valente@unimore.it> = ha scritto:


Il giorno 27/apr/2015, = alle ore 11:57, Toke H=F8iland-J=F8rgensen <toke@toke.dk> ha = scritto:

Paolo Valente <paolo.valente@unimore.it> = writes:

a network-monitoring company = got curious about bufferbloat issues and
asked me to investigate a = little bit the following issue (quite
interesting in my opinion). Is = it possible to detect, from outside a
node, if the node is = bufferbloated? In particular, the only action
allowed would be to = observe the packets entering and leaving the node
(plus, of course, = their timing).

Sure. Just measure the timing when = the network is unloaded and compare
it to when it is loaded to = capacity. We do that all the time.

The details of course depend = on what you define by a 'node', what role
it plays in the network = (does it forward or originate packets?), and
what control you have = over the traffic flowing through it. :)


Let us = consider, for example, a host with a VoIP call and a large-file transfer = in progress. My concern is: from inside the host, we can measure the = delays experienced by the VoIP application, but, form outside, how can = we detect that the application is experiencing a high latency, or, = indirectly, that there is bufferbloat and hence that the application is = likely to be experiencing a high latency? (Of course, I am also about to = read the documents suggested by Neil.)


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.

Of course, if a = bufferbloated state can be measured by other external measurements, then = we can infer the problem indirectly.

Are there flaws in my above = considerations?

Thanks,
Paolo

Thanks,
Paolo

-Toke


--
Paolo Valente =             &n= bsp;           &nbs= p;            =            
Algo= group
Dipartimento di Fisica, Informatica e Matematica
Via = Campi, 213/B
41125 Modena - Italy =           
homepage: =  http://algogroup.unimor= e.it/people/paolo/


--
Paolo Valente =             &n= bsp;           &nbs= p;            =            
Algo= group
Dipartimento di Fisica, Informatica e Matematica
Via = Campi, 213/B
41125 Modena - Italy =           
homepage: =  http://algogroup.unimor= e.it/people/paolo/

____________________________________________= ___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.buffer= bloat.net/listinfo/bloat

= --Apple-Mail=_E0165EF1-C17D-491F-AED8-9BB9EB1BD625--