From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id D51F321F22F for ; Mon, 27 Apr 2015 13:39:11 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t3RKdARQ024473; Mon, 27 Apr 2015 13:39:10 -0700 Date: Mon, 27 Apr 2015 13:39:10 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Paolo Valente In-Reply-To: <08759E4A-AF05-4C28-AE99-A61F8524218A@unimore.it> 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> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-572712272-1430167150=:18168" 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 20:39:40 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-572712272-1430167150=:18168 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 27 Apr 2015, Paolo Valente wrote: > Il giorno 27/apr/2015, alle ore 12:23, Toke Høiland-Jørgensen ha scritto: > >> Paolo Valente 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. What is it that you do have available? Bufferbloat usually isn't a huge problem on the leaf node where the applications are running. They usually have a fast local LAN link. Bufferbloat causes most of it's problems when it's on a middlebox where the available bandwidth changes so that one link becomes congested. 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. If you are trying to probe the network from the outside, without being able to even generate ping packets, then you have a problem. If you can monitor ping packets going into the network, you can figure out how long they take to get back out. 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) 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. David Lang --680960-572712272-1430167150=:18168--