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 C923121F2C5 for ; Mon, 4 May 2015 03:42:49 -0700 (PDT) Received: by labgd6 with SMTP id gd6so2818862lab.2 for ; Mon, 04 May 2015 03:42:47 -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=MpF6wIQuMzoV8hmbKc5QyBullzy8sa56Uuy2aP5bosc=; b=VAfuTQIEhNUXh0AgUg1/MGRm0lZKVLqETPSHfAgHHwXCUluOnGqRFBkhXCcQgw1tcD oBMPmuYioPv3h1KHsvK9KsiQgLfqN0goOw4550+6L5rIZG/ngLDUngPsGvQyJEDBmXfi dREo2bHPphgWeYEkhCQGZgHNmUdziuXxxu5CMc2K57bI2kJe3uHaB/VYawspCAPZDj02 HdRv53eQXW3iVYGSjgA5RxDMRN+XY0+Mpjad0IaEc2gaRmTJIanl97ZmbJiUjJr8eYK1 6So6fQffQgwY3brjy2kax70AJWyU5UU/mUvw4RoZv9Z9T0/TqjaYBRKj+5IZakIacw4o fjGw== X-Gm-Message-State: ALoCoQkindxll/0AEQ+yB+41KfCnLfhp7uuidELnJ+OVtK2ezic3Z5Vh6fkLDCqYtagiRQfxePLDiG7ZCrE4LtQaX+Yb3NhGCQ== X-Received: by 10.194.121.163 with SMTP id ll3mr31331574wjb.142.1430736167031; Mon, 04 May 2015 03:42:47 -0700 (PDT) Received: from mail.la.pnsol.com (eu1sys200aog106.obsmtp.com. [207.126.144.121]) by mx.google.com with SMTPS id k3sm272706wiz.1.2015.05.04.03.42.45 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 May 2015 03:42:47 -0700 (PDT) X-Relaying-Domain: pnsol.com Received: from mail.la.pnsol.com ([89.145.213.110]) (using TLSv1) by eu1sys200aob106.postini.com ([207.126.147.11]) with SMTP ID DSNKVUdNJU6t2EwPtPM87W7MrS6E3tvqAP0r@postini.com; Mon, 04 May 2015 10:42:46 UTC Received: from git.pnsol.com ([172.20.5.238] helo=roam.smtp.pnsol.com) by mail.la.pnsol.com with esmtp (Exim 4.76) (envelope-from ) id 1YpDpb-0006sI-N4; Mon, 04 May 2015 11:42:35 +0100 Received: from [172.20.5.110] by roam.smtp.pnsol.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1YpDpk-00000c-52; Mon, 04 May 2015 10:42:44 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_F4416497-CCBE-4272-936C-24BBF7033534" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Neil Davies In-Reply-To: Date: Mon, 4 May 2015 11:42:43 +0100 Message-Id: <5D20E7F1-37D0-4CD3-8793-C29149695C97@pnsol.com> 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) 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:43:19 -0000 --Apple-Mail=_F4416497-CCBE-4272-936C-24BBF7033534 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 4 May 2015, at 11:28, Jonathan Morton wrote: > 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 >=20 Yep, that corresponds to (=E2=88=86Q|G + =E2=88=86Q|S(min packet size)) = - note that the composition/de-composition only work on the individual = bases - i.e need to deal with the delay in terms of =E2=88=86Q|G = seperately. We call the =E2=88=86Q|G and =E2=88=86Q|S the "structural = delay" - as you point out needs change in some aspects of the network = elements/their arrangement. > Higher observed delays than this will tend to correspond to one or = both of the buffers at the bottleneck being persistently filled. >=20 the =E2=88=86Q|V (which can be established by measuring the delay and = subtracting the (=E2=88=86Q|G + =E2=88=86Q|S(packet size)) can measure = this as an instantaneous value (not just at a persistent filing) - we've = got measurements that show queues filling and emptying . > 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 >=20 To estimate the contention for the common resource you need more than = the load - you need the traffic pattern as well=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 >=20 Noting that, delay and loss is, of course, a natural consequence of = having a shared medium and that (sorry for being a bit contentious) - = bloat is a subjective not objective term as > 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 --Apple-Mail=_F4416497-CCBE-4272-936C-24BBF7033534 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 4 May 2015, at 11:28, Jonathan = Morton <chromatix99@gmail.com> = wrote:

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.



Yep, that = corresponds to (=E2=88=86Q|G + =E2=88=86Q|S(min packet size)) - note = that the composition/de-composition only work on the individual bases - = i.e need to deal with the delay in terms of =E2=88=86Q|G seperately. =  We call the =E2=88=86Q|G and =E2=88=86Q|S the "structural delay" - = as you point out needs change in some aspects of the network = elements/their arrangement.

Higher observed delays than this will tend to correspond to = one or both of the buffers at the bottleneck being persistently filled. =

the =E2=88=86Q|V (which can be established by = measuring the delay and subtracting the (=E2=88=86Q|G + =E2=88=86Q|S(packe= t size)) can measure this as an instantaneous value (not just at a = persistent filing) - we've got measurements that show queues filling and = emptying .


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.



To estimate the = contention for the common resource you need more than the load - you = need the traffic pattern as well 

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.



Noting that, = delay and loss is, of course, a natural consequence of having a shared = medium and that (sorry for being a bit contentious) - bloat is a = subjective not objective term as

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.

- Jonathan Morton


= --Apple-Mail=_F4416497-CCBE-4272-936C-24BBF7033534--