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 9488C21F29E for ; Mon, 4 May 2015 03:44:38 -0700 (PDT) Received: by labgd6 with SMTP id gd6so2820727lab.2 for ; Mon, 04 May 2015 03:44:36 -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:content-transfer-encoding:message-id:references :to; bh=wenRb0nIrN1fhBOUklAoNQGzS3kb50HuSjVKFciy7uo=; b=TGeG7p9Lb6HCuToB6W/J3B5ktetmlo5xkSArfxAV20mJW1uo6AWwTWd1hX85XGIpXn vNBiCo6MsGOIEyjw0OQdnC4y4H3OHHMyRsPnrZYNDHzY2j4WNv8KP11s20oNsasZqAUY SqJ0a1kQZxxjZVuAdO6wnUvU6gr52RcZa9gs2BmSiuidaicmhrhWDFFIdnOhx0c9wYqQ E4h7DjxvjxJHV0SVnTP5NtTJ3Lgvr+zgeU2zHsrOMTC/F4aEYqt0fcd0hHo3NNLNc8pd 4759MdlmD+4dqFf7Twpn/4Pr/Vgf4Xttp4fTS3frjpGB1K0ZU7GrJ2pHPFbbgTY0cihV xF4w== X-Gm-Message-State: ALoCoQmxFHSl2bLXOMQC17AFkSAZT2IGY7WkKZk7XUwbO/IMm0803ttaQ4AR61Ler3GJnd5CSOjPaOt5DUeXB8jf3VQEk4D3Ow== X-Received: by 10.194.3.77 with SMTP id a13mr40671057wja.104.1430736276839; Mon, 04 May 2015 03:44:36 -0700 (PDT) Received: from mail.la.pnsol.com (eu1sys200aog102.obsmtp.com. [207.126.144.113]) by mx.google.com with SMTPS id p7sm261624wia.4.2015.05.04.03.44.36 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 May 2015 03:44:36 -0700 (PDT) X-Relaying-Domain: pnsol.com Received: from mail.la.pnsol.com ([89.145.213.110]) (using TLSv1) by eu1sys200aob102.postini.com ([207.126.147.11]) with SMTP ID DSNKVUdNk5pd8huuJoD59A1OBKwUgQF4qWn2@postini.com; Mon, 04 May 2015 10:44:36 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 1YpDrO-0006sd-2U; Mon, 04 May 2015 11:44:26 +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 1YpDrW-00000g-Gm; Mon, 04 May 2015 10:44:34 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Neil Davies In-Reply-To: Date: Mon, 4 May 2015 11:44:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <57FECE9A-B4FB-4216-A081-A78B5489A237@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: Paolo Valente X-Mailer: Apple Mail (2.1878.6) Cc: Jonathan Morton , 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:44:39 -0000 On 4 May 2015, at 11:41, Paolo Valente wrote: > 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). Paolo, this is where the difference between =E2=88=86Q|G, =E2=88=86Q|S = and =E2=88=86Q|V are important - the extraction of the =E2=88=86Q|G and = =E2=88=86Q|S establishes the structural delay, differences from that = structural delay are caused by the contention for the onward = transmission resources. > Il giorno 04/mag/2015, alle ore 12:28, Jonathan Morton = ha scritto: >=20 >> 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 >=20 >=20 > -- > 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/ >=20