From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp26.sms.unimo.it (smtp26.sms.unimo.it [155.185.44.26]) (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 2164921F20F for ; Mon, 27 Apr 2015 03:53:28 -0700 (PDT) Received: from [212.84.39.131] (port=53549 helo=[192.168.15.101]) by smtp26.sms.unimo.it with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YmgfE-0004ay-6H; Mon, 27 Apr 2015 12:53:26 +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: <87k2wx3m4k.fsf@toke.dk> Date: Mon, 27 Apr 2015 12:53:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08759E4A-AF05-4C28-AE99-A61F8524218A@unimore.it> References: <87r3r53ncb.fsf@toke.dk> <04A0C729-6E87-49C6-84F7-3428F236CA15@unimore.it> <3DC1A2EA-6DDD-4FF9-AD12-BB509EFB96B8@unimore.it> <87k2wx3m4k.fsf@toke.dk> To: =?windows-1252?Q?Toke_H=F8iland-J=F8rgensen?= 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, 27 Apr 2015 10:53:57 -0000 Il giorno 27/apr/2015, alle ore 12:23, Toke H=F8iland-J=F8rgensen = ha scritto: > 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). That=92s 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. >=20 A ping was one of the first simple actions I suggested, but the answer = was, as above: no you cannot =91touch' 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 :) >=20 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 =20 Algogroup Dipartimento di Fisica, Informatica e Matematica =09 Via Campi, 213/B 41125 Modena - Italy =20 homepage: http://algogroup.unimore.it/people/paolo/