[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