From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from spostino.sms.unimo.it (spostino.sms.unimo.it [155.185.44.3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id D922221F29E for ; Mon, 4 May 2015 03:32:10 -0700 (PDT) Received: from [212.84.37.202] (port=54892 helo=[192.168.15.101]) by spostino.sms.unimo.it with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YpDfN-0004t8-Lk; Mon, 04 May 2015 12:32:02 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Paolo Valente In-Reply-To: Date: Mon, 4 May 2015 12:31:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87r3r53ncb.fsf@toke.dk> <04A0C729-6E87-49C6-84F7-3428F236CA15@unimore.it> <3DC1A2EA-6DDD-4FF9-AD12-BB509EFB96B8@unimore.it> <87k2wx3m4k.fsf@toke.dk> <08759E4A-AF05-4C28-AE99-A61F8524218A@unimore.it> To: David Lang X-Mailer: Apple Mail (2.1878.6) UNIMORE-X-SA-Score: -2.9 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, 04 May 2015 10:32:40 -0000 Il giorno 27/apr/2015, alle ore 22:39, David Lang ha = scritto: > On Mon, 27 Apr 2015, Paolo Valente wrote: >=20 >> Il giorno 27/apr/2015, alle ore 12:23, Toke H=F8iland-J=F8rgensen = ha scritto: >>=20 >>> Paolo Valente writes: >>>=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 >>> 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). >>=20 >> That=92s exactly what I was thinking about. Actually it seems the = only solution to me. >>=20 >> 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). >>=20 >> Any pointer to previous/current work on this topic? >>=20 >>> 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. >>>=20 >>=20 >> A ping was one of the first simple actions I suggested, but the = answer was, as above: no you cannot =91touch' the network! >>=20 >>> 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 :) >>>=20 >>=20 >> Then I guess that now I am trying to build a good mallet according to = the rules of the game for this company :) >>=20 >> 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. >=20 > What is it that you do have available? >=20 > Bufferbloat usually isn't a huge problem on the leaf node where the = applications are running. They usually have a fast local LAN link. >=20 > Bufferbloat causes most of it's problems when it's on a middlebox = where the available bandwidth changes so that one link becomes = congested. Thanks for this clarification. So there are at least two classes of = problems to look at: endogenous bufferbloat (unlikely, but probably = still to be controlled in a sound network-monitoring tool) and external = bufferbloat. >=20 > If you can monitor packets going in and out of such links, you should = be able to exactly measure the latency you get going through the device. >=20 > If you are trying to probe the network from the outside, without being = able to even generate ping packets, then you have a problem. >=20 > If you can monitor ping packets going into the network, you can figure = out how long they take to get back out. >=20 Being measures passive, I think I can only if some users/applications = happens to generate these packets. > Look for other protocols that should have a very fast response time. = DNS and NTP are probably pretty good options. HTTP requests for small = static pages aren't always reliable, but can be useful (or especially = ones that check for cache expiration, HTTP HEAD commands for example) >=20 > If you can look at such traffic over a shortish, but not tiny, = timeframe, you should be able to find the minimum response time for such = traffic, and that can give you a pretty good idea of the about of = minimum latency involved. >=20 Thanks a lot. Differently from ping, I guess that these types of traffic = are likely to be frequently in progress in typical networks. Could your considerations be further extended/generalized as follows: = for any node belonging to the network (being monitored), if the node = forwards packets, then we can detect somehow if it is suffering from = bufferbloat by measuring for how long it holds forwarded packets? (Which = is probably related to what Neil patiently tried to explain me in his = just-arrived email.) Thanks, Paolo > David Lang -- 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/