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 5FF1E21F1BC for ; Mon, 4 May 2015 03:41:34 -0700 (PDT) Received: from [212.84.37.202] (port=55269 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 1YpDoZ-0005dg-3t; Mon, 04 May 2015 12:41:31 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Paolo Valente In-Reply-To: Date: Mon, 4 May 2015 12:41:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <72DB0260-F0DF-426F-A3F3-ECF5D8AF228F@pnsol.com> <766042D4-0C90-4C77-9033-07B8E436C35B@pnsol.com> <2F4DCB53-1E46-4829-B2F8-F8131664D1FF@pnsol.com> <0F8CB21C-792F-4F95-BC49-BED3DF0A2100@unimore.it> To: Jonathan Morton 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:42:04 -0000 Thanks for this extra information and suggestions. Just to be certain = that I am not missing anything: I am assuming that also the observed = delay you mention is the delay observed from outside endpoints, and not = the total delay that one would obtain by adding also the queueing delays = inside end points (which, in my case, is one of the unobservable = quantities). Il giorno 04/mag/2015, alle ore 12:28, Jonathan Morton = ha scritto: > Generally, the minimum observed delay will correspond to the case when = both inbound and outbound queues are empty throughout the path. This = delay should correspond to basic propagation and forwarding delays, = which can't be reduced further without altering some aspect of the = network. >=20 > Higher observed delays than this will tend to correspond to one or = both of the buffers at the bottleneck being persistently filled. To work = out which one, you'll need to estimate the network load in each = direction. This is of course easiest if you can see all or most of the = traffic passing the bottleneck link, or if you yourself are = participating in that load, but it's probably possible in some other = situations if you get creative. >=20 > To determine that bloat is NOT present, you need to observe delays = that are close to the baseline unloaded condition, while also being = fairly sure that the bottleneck link is saturated in the relevant = direction. >=20 > The most reliable indication of link saturation is to observe ECN = marked packets, which will only normally be produced by an AQM algorithm = signalling link congestion (where both endpoints of the flow have = negotiated ECN support). A slightly less reliable indication of = saturation is to observe lost packets, either via retransmission or ack = patterns, especially if they occur in bursts or at remarkably regular = intervals. >=20 > - Jonathan Morton -- 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/