From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gpo2.cc.swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9F0113B260 for ; Sat, 27 Aug 2016 01:02:32 -0400 (EDT) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo2.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id u7R52T2w021894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 27 Aug 2016 15:02:29 +1000 To: bloat@lists.bufferbloat.net References: <0B9BB2F0-611E-4388-8784-0AC71556AB4B@cable.comcast.com> <20160824090847.4e77ce8f@xeon-e3> <1C99BD90-7688-4168-814D-57DA12F0F08C@cable.comcast.com> <90667e99-1334-af36-5879-3b4ed362ed68@pollere.com> From: grenville armitage Message-ID: <57C11EE5.8020404@swin.edu.au> Date: Sat, 27 Aug 2016 15:02:29 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090604040305030609060002" Subject: Re: [Bloat] Open Source Speed Test (was fast.com - Netflix's speed monitoring) X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 05:02:33 -0000 This is a multi-part message in MIME format. --------------090604040305030609060002 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 08/27/2016 11:06, David Lang wrote: > On Fri, 26 Aug 2016, Kathleen Nichols wrote: > [..] >>> so you can call it large queues instead of large buffers, but the result >>> is that packets end up being 'in transit' for a long time. >> >> No, a large queue is a bunch of packets waiting in a queue (which is contained in a buffer). A large buffer with zero or a small number of packets in it is not going to result in packets being in transit for a long time. [..] > > I don't understand what you are trying to call out by trying to change the terminology. I think you're almost in violent agreement, except that Kathy is differentiating between the space set aside for holding between 0 and N packets (or bytes) of data for delivery (a /buffer/) and an instance of packets queued up to a particular depth in a buffer (a /queue/) . Given that terminology, a bottleneck may implement a large buffer, but with proper congestion signals (or eg. delay-based congestion inference by end points) there might only ever be small queues build up in the (large) buffer. cheers, gja --------------090604040305030609060002 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 08/27/2016 11:06, David Lang wrote:=
On Fri, 26 Aug 2016, Kathleen Nichols wrote:

=C2=A0=C2=A0=C2=A0 [..]
so you can call it large queues instead= of large buffers, but the result
is that packets end up being 'in transit' for a long time.

No, a large queue is a bunch of packets waiting in a queue (which is contained in a buffer). A large buffer with zero or a small number of packets in it is not going to result in packets being in transit for a long time.
=C2=A0=C2=A0=C2=A0 [..]

I don't understand what you are trying to call out by trying to change the terminology.

I think you're almost in violent agreement, except that Kathy is differentiating between the space set aside for holding between 0 and N packets (or bytes) of data for delivery (a buffer) and an instance of packets queued up to a particular depth in a buffer (a queue) . Given that terminology, a bottleneck may implement a large buffer, but with proper congestion signals (or eg. delay-based congestion inference by end points) there might only ever be small queues build up in the (large) buffer.

cheers,
gja

--------------090604040305030609060002--