From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::231]) (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 6394A21F2A1 for ; Mon, 4 May 2015 03:28:35 -0700 (PDT) Received: by vnbf1 with SMTP id f1so14258910vnb.5 for ; Mon, 04 May 2015 03:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JZYOxqJoa96Sjbu9qoRROHGW11f8laC8erGAbagjVYQ=; b=bKzZqsyh9QLDX+RgIQmn7YUQv1CESGXmKkXIUMxMoAxph1kVv+Ak0Dcgbljm0NxcdQ iDcPGFVMPpWxAnWHmonYK0Qyk+ezXLt7j7DCbiLQxf4TYeS3bfpRYdoVFwSiVOUanZ19 N0jvrxsJ94yH37NbxqXB1F6M0zJszmOCFQGcIY2cCoclgf6e50048z+zK09BM96SBDTt 4RXyP4eRUEiVtQyKuNp6BQ8lKlQz0BNJGAYAZKjRkeIe+owlHNIFbxDK7BHCvzq4zVZN iotk92tRgCfPfert/UuyJ7MZVd5PdmFbI5jnaI4vxWHrWZCcqPGnq++7j3RPTOZTOzM9 QXKA== MIME-Version: 1.0 X-Received: by 10.52.251.107 with SMTP id zj11mr25622437vdc.96.1430735311439; Mon, 04 May 2015 03:28:31 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Mon, 4 May 2015 03:28:31 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Mon, 4 May 2015 03:28:31 -0700 (PDT) In-Reply-To: <0F8CB21C-792F-4F95-BC49-BED3DF0A2100@unimore.it> 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> Date: Mon, 4 May 2015 13:28:31 +0300 Message-ID: From: Jonathan Morton To: Paolo Valente Content-Type: multipart/alternative; boundary=001a1134d45e018eb105153f0664 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:29:07 -0000 --001a1134d45e018eb105153f0664 Content-Type: text/plain; charset=UTF-8 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. 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. 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. 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 --001a1134d45e018eb105153f0664 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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, wh= ich can't be reduced further without altering some aspect of the networ= k.

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 di= rection. This is of course easiest if you can see all or most of the traffi= c 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 c= reative.

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= .

The most reliable indication of link saturation is to observ= e ECN marked packets, which will only normally be produced by an AQM algori= thm signalling link congestion (where both endpoints of the flow have negot= iated ECN support). A slightly less reliable indication of saturation is to= observe lost packets, either via retransmission or ack patterns, especiall= y if they occur in bursts or at remarkably regular intervals.

- Jonathan Morton

--001a1134d45e018eb105153f0664--