From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 593803B260 for ; Wed, 3 Aug 2016 22:13:37 -0400 (EDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id u742DXfq011549; Wed, 3 Aug 2016 19:13:33 -0700 Date: Wed, 3 Aug 2016 19:13:33 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: grenville armitage cc: bloat@lists.bufferbloat.net, aqm@ietf.org In-Reply-To: <57A28F9D.8060506@swin.edu.au> Message-ID: References: <84e6b7ab-b7e6-10c0-084a-bd5cb5d4b03f@taht.net> <595be984-efaa-8cbf-3376-1f29150e200d@pollere.com> <57A28F9D.8060506@swin.edu.au> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-1626825009-1470276813=:2015" Subject: Re: [Bloat] [aqm] pie, codel, fq_pie, fq_codel tech report 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: Thu, 04 Aug 2016 02:13:37 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-1626825009-1470276813=:2015 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 4 Aug 2016, grenville armitage wrote: > Kathy, Dave, > > Thanks for the +ve comments! > > On 08/04/2016 03:03, Kathleen Nichols wrote: >> Nicely laid out and reported, but I have a question for the authors. At the >> top of section II. D. it says: >> "Instantaneous’ throughput is an approximation derived >> from the actual bytes transferred during constant windows >> of time." >> >> Is the "actual bytes transferred" the sum of the packet sizes through >> the link or is it the actual advance in sequence number bytes? > > Simplistic sum of the IP payload lengths per unit time as seen at the > destination's NIC. (We took the line of least resistance for this tech > report. But yes, the advance of sequence num. per unit time would be a more > precise estimate of the useful flow of bytes as experienced by the > application.) I would argue that bytes seen by the wire (or any router in the middle) is a far more useful thing to track than what the application sees. If one application is layered inside 5 different VPNs or other encapsulation, while another is native on the wire, we care about the fairness of how the wire is used. If we have something like ATM where transmissions are in quantums, we need to take this into account. If we have something like wifi where a transmit slot is X overhead + Y*bytes (where 2-3K * Y = X or worse), if you don't take the overhead into account and just look at the application level data bytes passed you end up with such a distorted picture of what's going on that it's almost useless. David Lang --680960-1626825009-1470276813=:2015--