Re: [aqm] Gathering Queue Length Statistics

Ryan Doyle <rpdoyle@live.unc.edu> Thu, 26 February 2015 04:40 UTC

Return-Path: <prvs=4924feaa2=rpdoyle@live.unc.edu>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C691A00F9 for <aqm@ietfa.amsl.com>; Wed, 25 Feb 2015 20:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 UxyuhEh4Qn3M for <aqm@ietfa.amsl.com>; Wed, 25 Feb 2015 20:40:36 -0800 (PST)
Received: from mxip11i.isis.unc.edu (mxip11i.isis.unc.edu [152.2.0.32]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C9C1A000F for <aqm@ietf.org>; Wed, 25 Feb 2015 20:40:35 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2C7BQC2oO5U/8BPAphbgj9DUlqEWr0NgR8dAQuFbgKBKjgUAQEBAQEBAXyEDwEBAQEBAQEBAQEPXAsFCwsRAwECAS4hBgEnCAYOBSKHeAEDCQgNsEoBjTORTQ1FhHsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixOCRCaBcAMRB4MXgRQFiiIuiHODRlmCYYMagiEwhjOCSoM+I4F/AxyBblEBgkIBAQE
X-IPAS-Result: A2C7BQC2oO5U/8BPAphbgj9DUlqEWr0NgR8dAQuFbgKBKjgUAQEBAQEBAXyEDwEBAQEBAQEBAQEPXAsFCwsRAwECAS4hBgEnCAYOBSKHeAEDCQgNsEoBjTORTQ1FhHsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixOCRCaBcAMRB4MXgRQFiiIuiHODRlmCYYMagiEwhjOCSoM+I4F/AxyBblEBgkIBAQE
X-IronPort-AV: E=Sophos; i="5.09,650,1418101200"; d="scan'208,217"; a="39209003"
Received: from its-msxht7f.ad.unc.edu ([152.2.79.192]) by mxip11o.isis.unc.edu with ESMTP/TLS/AES128-SHA; 25 Feb 2015 23:40:34 -0500
Received: from mail.hotmail.com (172.22.44.34) by smtp.unc.edu (152.2.79.192) with Microsoft SMTP Server id 14.3.224.2; Wed, 25 Feb 2015 23:40:34 -0500
Received: from BAY176-W51 ([157.56.23.7]) by COL004-WSS1S6.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Wed, 25 Feb 2015 20:40:32 -0800
X-TMN: [K43ntQlD2W+T+TOpy6fxITjdGRqfLPV4]
Message-ID: <BAY176-W5148D8EFEF0CCC5D1E94FBA5140@phx.gbl>
Content-Type: multipart/alternative; boundary="_a682fc52-8933-41a6-802f-ab6a55edd62e_"
From: Ryan Doyle <rpdoyle@live.unc.edu>
To: Dave Taht <dave.taht@gmail.com>
Date: Wed, 25 Feb 2015 23:40:31 -0500
Importance: Normal
In-Reply-To: <CAA93jw5dPhLmamcSHxD92b50XxmkkZNy28SWMkOSRFzBY3keBA@mail.gmail.com>
References: <BAY176-W35105790F5BC047AA12309A5170@phx.gbl>, <CAA93jw5dPhLmamcSHxD92b50XxmkkZNy28SWMkOSRFzBY3keBA@mail.gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Feb 2015 04:40:32.0532 (UTC) FILETIME=[5AD40D40:01D0517E]
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/sR6XAdYkWIYdfbelEv2czJpWbgk>
Cc: "brouer@redhat.com" <brouer@redhat.com>, "aqm@ietf.org" <aqm@ietf.org>, "dhavey@yahoo.com" <dhavey@yahoo.com>, "fred@cisco.com" <fred@cisco.com>
Subject: Re: [aqm] Gathering Queue Length Statistics
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 26 Feb 2015 04:40:44 -0000

Thank you very much for taking the time to write your response and link me to the resources. 

I am planning on creating CDFs and have no intention of using average queue length as a primary statistic in my research. I am putting much more emphasis on end to end delays. That said, I am interested in taking sample measurements of instantaneous queue length, but am really looking for any queue-length statistics the AQMs may measure.

Best,
Ryan Doyle

p.s. Thank you to everyone else that responded as well. I will be sure to look at all of the links, but can't respond to everything individually.

> Date: Wed, 25 Feb 2015 10:24:45 -0800
> From: dave.taht@gmail.com
> To: rpdoyle@live.unc.edu
> CC: aqm@ietf.org
> Subject: Re: [aqm] Gathering Queue Length Statistics
> 
> On Wed, Feb 25, 2015 at 9:53 AM, Ryan Doyle <rpdoyle@live.unc.edu> wrote:
> > Hello,
> >
> > I am a senior undergraduate student at the University of North Carolina at
> > Chapel Hill and am studying the effectiveness of AQMs. I have set up a lab
> > network and plan on running different sets of experiments with different
> > AQMs. My router machines are running Linux kernel version 3.16.0.
> >
> > I am using the fq_codel, codel, and pie qdiscs for my research and am
> > wondering if there is a way to collect statistics regarding the average
> > queue length since a qdisc was enabled? I have looked at tc's "-s" flag for
> > statistics, but they show nothing about queue length and I have been unable
> > to find anything else that might help me get queue length statistics.
> 
> Oh, god. I am getting incredibly sensitive about average queue length,
> and I realize that that is not what you meant. But since not enough
> people have seemingly read this or any of the related materials, here
> it is again.
> 
> http://www.pollere.net/Pdfdocs/QrantJul06.pdf
> 
> And I of course always recommend van´s talk on the fountain model for
> thinking about closed loop servo systems.
> 
> http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos
> 
> In the bufferbloat project...
> 
> We have developed many tools that drive aqms hard, see netperf-wrapper
> on github for that, which measures e2e delay without requiring any
> tools on the routers inbetween. e2e delay in my mind is way more
> important than average queue length. And you can derive the queue
> length(s) from tcp timestamps in those netperf-wrapper tests, from
> additional packet captures, if you must.
> 
> If you absolutely MUST derive average queue length from the box, you
> can poll the interface frequently with tc -s qdisc show as well as
> with ifconfig- and parse out the number of packets and the number of
> bytes. But you can do MUCH more valid statistical analysis than that,
> with that sort of data set - and if you poll too frequently you will
> heisenbug your tests, as those data collection calls take locks that
> interfere with the path. and we have all sorts of advice about traps
> for the unwary here:
> 
> http://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel
> 
> 
> Please use things like CDFs to see the range of delays, rather than
> averages. It is what happens at above 90% of the range that makes
> bufferbloat maddening to ordinary users.
> 
> I am summarily rejecting any papers that I review that report average
> queue length as if it meant anything. And for a few other reasons. You
> have been warned. I really lost my temper after the last paper I
> reviewed last weekend and the resulting flamage is all over the bloat
> list and codel lists, and starts here:
> 
> https://lists.bufferbloat.net/pipermail/codel/2015-February/000872.html
> 
> 
> > Best,
> > Ryan Doyle
> >
> > _______________________________________________
> > aqm mailing list
> > aqm@ietf.org
> > https://www.ietf.org/mailman/listinfo/aqm
> >
> 
> 
> 
> -- 
> Dave Täht
> Let's make wifi fast, less jittery and reliable again!
> 
> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
> 
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm