[Bloat] [aqm] DOCSIS 3.1 support for AQM

Greg White g.white at CableLabs.com
Mon Nov 4 18:20:46 EST 2013


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 at gmail.com<mailto:woody77 at gmail.com>>
Date: Thursday, October 31, 2013 at 7:23 AM
To: bloat <bloat at lists.bufferbloat.net<mailto:bloat at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20131104/b9c90ccc/attachment-0002.html>


More information about the Bloat mailing list