Re: [aqm] RFC 8290 on The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm

rfc-edi...@rfc-editor.org writes: > A new Request for Comments is now available in online RFC libraries. > > > RFC 8290 > > Title: The Flow Queue CoDel Packet > Scheduler and Active Queue Management Algorithm Yay! Happy new year to all! :D

Re: [aqm] CoDel: After much ado ...

"Mirja Kuehlewind (IETF)" writes: > Thanks! Will approve now! Finally! Yeah! And there was much rejoicing! Wooh! :) -Toke ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Warren Kumari's Yes on draft-ietf-aqm-codel-07: (with COMMENT)

Toke Høiland-Jørgensen <t...@toke.dk> writes: > Jana Iyengar <j...@google.com> writes: > >> Yup, coming up next week. > > Or maybe this week? ;) So, any chance of getting this submitted before the cutoff date on Monday? -Toke __

Re: [aqm] Warren Kumari's Yes on draft-ietf-aqm-codel-07: (with COMMENT)

Jana Iyengar writes: > Yup, coming up next week. Or maybe this week? ;) -Toke ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Warren Kumari's Yes on draft-ietf-aqm-codel-07: (with COMMENT)

Jana Iyengar writes: > +1 to Mirja's response. I'll do some restructuring. Thanks for your > comments! Any progress on said restructuring? :) -Toke ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] status of codel WGLC

Jana Iyengar writes: > We'll send out a revised draft early next week. Soo... Ping? -Toke ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] status of codel WGLC

Dave Täht writes: > On 9/14/16 6:26 AM, Wesley Eddy wrote: >> 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 >>

[aqm] Applying AQM to the WiFi MAC layer

Since Andrew McGregor mentioned this at the mic during the tsvwg/aqm session in Berlin, I thought I'd post some references to the work on fixing queueing behaviour on WiFi (by incorporating principles from FQ-CoDel in the Linux WiFi stack at the MAC layer). There are still some bugs to work out,

Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC

Dave Cridland writes: > If this isn't standards track because there's no WG consensus for a single > algorithm (and we'll argue over whether a queueing algorithm is a protocol or > not some other time), then I think this WG document should reflect that > consensus and hold

Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC

Dave Cridland writes: > What we meant to say was something along the lines of "You want to turn > this on; it'll do you good, so get on with it! You won't regret it! Now > go fix the next 100 million devices!". The current formulation in the > draft is an

Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC

Dave Cridland writes: > Actually I'd read that as more of a recommendation than merely safe. I > think by safe, the authors mean that no significant harm has been > found to occur. What we meant to say was something along the lines of "You want to turn this on; it'll do you

Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC

grenville armitage writes: > What about: > > Section 1: "...and we believe it to be safe to turn on by default, ..." -> > "...and we believe it to be significantly beneficial to turn on by default, > ..." > Section 7: "We believe it to be a safe default and ..." -> "We

Re: [aqm] Alia Atlas' No Objection on draft-ietf-aqm-fq-codel-05: (with COMMENT)

Dave Taht writes: >> I've added a reference pointing to the fq_codel code in Linux git tree >> to the latest updated version, available here: >> https://kau.toke.dk/ietf/draft-ietf-aqm-fq-codel-06.html (or .txt). > > I'm not huge on calling this reference [LINUX].

Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC

Hi Bob Thank you for your timely and constructive comments. Please see the inline responses below. > My main concern is with applicability. In particular, the sentence in > section 7 on Deployment Status: "We believe it to be a safe default > and encourage people running Linux to turn it on:

Re: [aqm] Spencer Dawkins' Yes on draft-ietf-aqm-fq-codel-05: (with COMMENT)

"Spencer Dawkins" writes: > -- > COMMENT: > -- > > Very nice work. I have some nit-ish questions I hope you'll consider, > but

Re: [aqm] Experimental vs informational vs standards track

Wesley Eddy writes: > IMHO, Standards Track carries more weight to say that there are no > sharp corners, and the IETF is pretty sure this works well. > Experimental is more cautious saying this looks pretty useful, and you > should consider trying it out, but it might have

Re: [aqm] A question regarding the latest FQ-CoDel Internet-Draft

"Agarwal, Anil" writes: > Might be beneficial to fix the following line in section 5.4 - > >int deficit; /* this is the queue credit */ Yeah, I'm aware of that. Couldn't decide what to do about the fact that the Linux code calls it 'deficit' instead of

Re: [aqm] I-D Action: draft-ietf-aqm-fq-codel-02.txt

> Authors : Toke Høiland-Jørgensen > Paul McKenney > Dave Taht > Jim Gettys > Eric Dumazet > Filename: draft-ietf-aqm-fq-codel-02.txt >

Re: [aqm] ECT(1)

Bob Briscoe writes: > Yes, and because flow-queuing overrides the packet rate choices of > applications (breaking the end-to-end principle). In testing, fq > completely rips apart CBR and variable rate video when running > alongside long-running TCP flows, when they

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

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 have an analysis of transient behaviour in my recent paper (section

Re: [aqm] FQ-PIE kernel module implementation

Fred Baker (fred) f...@cisco.com writes: I'm not sure it makes sense to discuss fq_codel having a separate instance for each queue. Why not? It does. Completely separate state variables and everything... It could, I suppose (by having a separate target delay value for each queue), but...

Re: [aqm] References on AQM test results and fq_nocodel

David Lang da...@lang.hm writes: if the fq portion is being gamed, how severe can the imbalance be? Is it a matter that if there are N flows without gaming the system, and each is getting 1/N bandwith, then if a cheater uses M flows the cheater gets M/(N+M) of the bandwidth? Yes, not

Re: [aqm] adoption call: algorithm drafts

Dave Taht dave.t...@gmail.com writes: I agree it relies heavily on the codel draft to keep the distinction between flow queuing and aqm distinct. If it were to include codel (or vice versa), the draft would get rather long. IMO it would be quite possible to make the description AQM-agnostic;

Re: [aqm] [Bloat] the side effects of 330ms lag in the real world

Jim Gettys j...@freedesktop.org writes: Now, if someone gives me real fiber to the home, with a real switch fabric upstream, rather than gpon life might be somewhat better (if the switches aren't themselves overbuffered But so far, it isn't. As a data point for this, I have fibre to my

Re: [aqm] [AQM Evaluation Guidelines]

Nicolas KUHN nicolas.k...@telecom-bretagne.eu writes: and realistic HTTP web traffic (repeated download of 700kB). As a reminder, please find here the comments of Shahid Akhtar regarding these values: The Cablelabs work doesn't specify web traffic as simply repeated downloads of 700KB, though.

[aqm] Draft on fq_codel submitted

Hi everyone This is to notify you of the availability of a draft explaining the fq_codel algorithm. It is available from here: http://datatracker.ietf.org/doc/draft-hoeiland-joergensen-aqm-fq-codel/ Thanks, -Toke ___ aqm mailing list aqm@ietf.org

Re: [aqm] [AQM Evaluation Guidelines]

Nicolas KUHN nicolas.k...@telecom-bretagne.eu writes: I believe the draft must be the most generic the possible. These guidelines provide the tools and aspects that must be looked at, however the AQM is tested. Even-driven simulations (such as in NS-2,OMNET) enable to achieve an economical