Re: [aqm] DOCSIS 3.1 support for AQM

Hi Greg, Am 30.10.2013 21:13, schrieb Greg White: Cable modems are required to implement a variant of PIE (detailed in Annex M of MAC and Upper Layer Protocols Interface Specification http://www.cablelabs.com/specifications/CM-SP-MULPIv3.1-101-131029.pdf) as the default AQM. Modem vendors

Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt

Hi, On 13.05.2015 at 07:01 Fred Baker (fred) wrote: On May 12, 2015, at 9:06 PM, Simon Barber si...@superduper.net wrote: Where would be the best place to see if it would be possible to get agreement on a global low priority DSCP? I’d suggest https://tools.ietf.org/html/rfc4594 4594

[aqm] Any aqm evaluation at speeds =10Gbit/s?

Hi, has anyone recently tested AQMs like Codel or PIE at speeds of =10Gbit/s? If so, where are the results available? Pointers greatly appreciated... Regards, Roland ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] FQ-PIE kernel module implementation

Hi, thanks for your analysis. Indeed, Polina came up with a similar analysis for an unresponsive UDP flow and a TCP flow. Flow queueing can achieve link share fairness despite the presence of unresponsive flows, but is ineffective if the AQM is applied to the aggregate and not to the individual

[aqm] PIE vs. RED

Hi, while looking at the PIE presentation http://www.ietf.org/proceedings/86/slides/slides-86-iccrg-5.pdf, slide 6 shows that RED is far away from the PIE queuing delay. However, I'm not sure that this comparison is really fair if looking at the choice of the parameters. The buffer limit is set

Re: [aqm] TCP ACK Suppression

Hi, Am 07.10.2015 um 09:42 schrieb LAUTENSCHLAEGER, Wolfram (Wolfram): > Is this specialized upstream TCP ACK handling, particularly the > prioritization a general recommendation in all access technologies? > Perhaps it should be, since otherwise up and downstream TCP flows interfere > in a

Re: [aqm] CoDel's control law that determines drop frequency

Hi, Am 30.09.2015 um 15:02 schrieb Bob Briscoe: > Yes, Toke's right - I was talking about how fast the control law moves, > not the steady state. Ok, talking past each other...I meant steady state of TCP flows and not steady state of CoDel, i.e. CA phase not slow start. Sorry for the confusion.

Re: [aqm] CoDel's control law that determines drop frequency

Hi, Am 30.09.2015 um 13:52 schrieb Toke Høiland-Jørgensen: > Polina Goltsman writes: > >>> Early on, Rong Pan showed that it takes CoDel ages to bring high load under >>> control. I think this linear increase is the reason. >> >> Is there a link to this ? > > I

Re: [aqm] working group last call on CoDel drafts

Dear all, we believe that the Codel specification https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ needs at least one major clarification. The following lines are present in the draft's pseudo-code, but are not explained further anywhere in the document text, and moreover differ from the

Re: [aqm] status of codel WGLC

Hi Jana, Am 29.09.2016 um 18:29 schrieb Jana Iyengar: > There are two issues in that email: > 1. The importance of reentering state. This is clearly a matter for > evaluation, and further evaluation will surely yield more results. We > cannot and won't be perfect in this draft, but I encourage

Re: [aqm] status of codel WGLC

Hi Wes and all, Am 14.09.2016 um 15:26 schrieb Wesley Eddy: > Hi, for awhile, the CoDel draft was in working group last call. Some > comments were received, and the authors made an update some time ago. > There hasn't been much follow-up discussion. I assume this means the > current draft meets

Re: [aqm] [tcpPrague] L4S status update

Hi Ingemar, my point was that it's probably better to refrain from building CC-specific behavior into network elements as the CC algorithms may evolve faster and in more flexible ways than we can foresee. Thus, it would be good to have a separation (or coupling) scheme that actually doesn't

Re: [aqm] Questioning each PIE heuristic

Hi, Am 28.03.2017 um 13:39 schrieb Fred Baker: > I'm not convinced I understand the definitions of "work conserving" > and "non work conserving" in this context. A "work conserving" > scheduling algorithm keeps an interface transmitting as long as there > is data in the queue, while a

Re: [aqm] Status of the GSP AQM?

Hi Wesley, Am 14.12.2017 um 22:59 schrieb Wesley Eddy: > I mentioned GSP as a possible work item, back when we were discussing > rechartering, but apparently it was not compelling to the group at that > time. > > When we did the AQM algorithm adoption call ~2014, GSP appeared to be > basically

[aqm] Policy-oriented AQM Steering (was Re: Status of the GSP AQM?)

Hi all, in our paper "Policy-oriented AQM Steering" that will be published at Networking 2018 shortly, we used also plain GSP and CoDel for comparison. Maybe this is convincing enough that GSP is also worth to be considered as alternative. We especially found it much easier to implement AQM