Re: [aqm] [Bloat] pie, codel, fq_pie, fq_codel tech report
Kathleen Nichols <nichols@pollere.com> Thu, 04 August 2016 15:29 UTC
Return-Path: <nichols@pollere.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A50912D642 for <aqm@ietfa.amsl.com>; Thu, 4 Aug 2016 08:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBdx4PC-ldbC for <aqm@ietfa.amsl.com>; Thu, 4 Aug 2016 08:29:18 -0700 (PDT)
Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28AC612D616 for <aqm@ietf.org>; Thu, 4 Aug 2016 08:29:18 -0700 (PDT)
Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 70EBA1E9E7; Thu, 4 Aug 2016 08:29:17 -0700 (PDT)
Received: from kmnimac.local (unknown [50.136.231.153]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nichols@pollere.net) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 4CBA31E9E6; Thu, 4 Aug 2016 08:29:17 -0700 (PDT)
To: bloat@lists.bufferbloat.net
References: <84e6b7ab-b7e6-10c0-084a-bd5cb5d4b03f@taht.net> <595be984-efaa-8cbf-3376-1f29150e200d@pollere.com> <57A28F9D.8060506@swin.edu.au> <alpine.DEB.2.02.1608031906350.2015@nftneq.ynat.uz>
From: Kathleen Nichols <nichols@pollere.com>
Message-ID: <26a25e02-80fc-6555-10cb-5d9eadd54e5d@pollere.com>
Date: Thu, 04 Aug 2016 08:29:16 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.02.1608031906350.2015@nftneq.ynat.uz>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/aqm/UR5YuCFhNol0om5yyAb49ngoskM>
Cc: aqm@ietf.org
Subject: Re: [aqm] [Bloat] pie, codel, fq_pie, fq_codel tech report
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Aug 2016 15:29:20 -0000
David, It is not necessarily "either-or". Tracking the forward progress of data sees lets you evaluate the effectiveness of the protocol, aqm, scheduling, and any other elements of the network. That doesn't mean other metrics can't be tracked. Kathie On 8/3/16 7:13 PM, David Lang wrote: > 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 > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat >
- Re: [aqm] [Bloat] pie, codel, fq_pie, fq_codel te… Kathleen Nichols
- Re: [aqm] [Bloat] pie, codel, fq_pie, fq_codel te… David Lang
- Re: [aqm] [Bloat] pie, codel, fq_pie, fq_codel te… grenville armitage
- Re: [aqm] [Bloat] pie, codel, fq_pie, fq_codel te… Kathleen Nichols
- [aqm] pie, codel, fq_pie, fq_codel tech report Dave Täht