From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by huchra.bufferbloat.net (Postfix) with ESMTP id A1238208ABD for ; Mon, 4 Nov 2013 15:20:50 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id rA4NKls9013011; Mon, 4 Nov 2013 16:20:47 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 04 Nov 2013 16:20:46 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Mon, 4 Nov 2013 16:20:46 -0700 From: Greg White To: Aaron Wood , bloat , "aqm@ietf.org" Thread-Topic: [Bloat] [aqm] DOCSIS 3.1 support for AQM Thread-Index: AQHO1hLGwCMHKHWaMUWxuDtUWCG/VZoPMUmAgAZ6x4A= Date: Mon, 4 Nov 2013 23:20:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_CE9D77732152Cgwhitecablelabscom_" MIME-Version: 1.0 Subject: Re: [Bloat] [aqm] DOCSIS 3.1 support for AQM 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 Nov 2013 23:20:51 -0000 --_000_CE9D77732152Cgwhitecablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rong will cover this at a high-level during the IETF AQM session tomorrow. = Her slides are posted: ?www.ietf.org/proceedings/88/slides/slides-88-aqm-1.pdf I plan to do a follow-up to the paper you linked to below to give some of t= he details. Should be ready before IETF89. -Greg From: Aaron Wood > Date: Thursday, October 31, 2013 at 7:23 AM To: bloat > Subject: Re: [Bloat] [aqm] DOCSIS 3.1 support for AQM Thanks for the information. I'd be interested in why you have chosen PIE, e.g., instead of sfq-CoDel. Any pointers to evaluation reports/results? Last time I saw a presentation on this it seemed that CoDel was performing quite well. I think this cablelabs report makes the argument for PIE: http://www.cablelabs.com/downloads/pubs/Active_Queue_Management_Algorithms_= DOCSIS_3_0.pdf Mostly in that in the heavy traffic scenarios, PIE outperforms sfq_codel, a= nd in general is a tad bit better than codel, with a simpler implementation= (I think). Although I think I take issue with the "heavy traffic" model, = but I'm guessing (hoping) that it's based on surveys of customer traffic. = 60-110 upstream flows seems like a lot. But it's based around a heavy use = of BitTorrent, so maybe that's reasonable for some people. But in all other cases, sfq really blows the doors off of the others. -Aaron --_000_CE9D77732152Cgwhitecablelabscom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5A9D96C8D6D39B4FA8B99E077EBA7FB8@cablelabs.com> Content-Transfer-Encoding: quoted-printable
Rong will cover this at a high-level during the IETF AQM session tomor= row.  Her slides are posted:


I plan to do a follow-up to the paper you linked to below to give some= of the details.  Should be ready before IETF89.

-Greg

From: Aaron Wood <woody77@gmail.com>
Date: Thursday, October 31, 2013 at= 7:23 AM
To: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [aqm] DOCSIS 3= .1 support for AQM


Thanks for the information. I'd be interested in why you have chosen
PIE, e.g., instead of sfq-CoDel. Any pointers to evaluation
reports/results? Last time I saw a presentation on this it seemed
that CoDel was performing quite well.

I think this cablelabs report makes the argument for PIE:


Mostly in that in the heavy traffic scenarios, PIE outperforms sfq_cod= el, and in general is a tad bit better than codel, with a simpler implement= ation (I think).  Although I think I take issue with the "heavy t= raffic" model, but I'm guessing (hoping) that it's based on surveys of customer traffic.  60-110 upstream flows see= ms like a lot.  But it's based around a heavy use of BitTorrent, so ma= ybe that's reasonable for some people.

But in all other cases, sfq really blows the doors off of the others.<= /div>

-Aaron
--_000_CE9D77732152Cgwhitecablelabscom_--