Re: [Bloat] [aqm] DOCSIS 3.1 support for AQM

[Greg White <g.white@CableLabs.com>]

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

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<http://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 the details.  Should be ready before IETF89.

-Greg

From: Aaron Wood <woody77@gmail.com<mailto:woody77@gmail.com>>
Date: Thursday, October 31, 2013 at 7:23 AM
To: bloat <bloat@lists.bufferbloat.net<mailto: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:

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, and 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

[-- Attachment #2: Type: text/html, Size: 3076 bytes --]