Re: [aqm] [AQM Evaluation Guidelines]

Nicolas KUHN writes: > Please let us know what you think of the current document. Hi Nicolas and others Thank you for the draft; here are some comments, mostly of a more general nature (as opposed to concrete proposals for rewording). 1. TESTING METHODOLOGY AND REPRODUCIBILITY I think it is i

Re: [aqm] [AQM Evaluation Guidelines]

Nicolas KUHN writes: > We tried to be the clearer the possible. > If you have any comments or proposals, we would be glad to hear them. Well, one thing I believe is worth addressing is the issue of simulation vs experiments on real systems. I would not consider an algorithm that has never been

Re: [aqm] [AQM Evaluation Guidelines]

Nicolas KUHN 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 and fast protocol > experimenta

[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 https

Re: [aqm] [AQM Evaluation Guidelines]

Nicolas KUHN 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. Quoting from [0], the actual

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

Jim Gettys 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 apartment buildin

Re: [aqm] adoption call: algorithm drafts

Dave Taht 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; and I do believe

Re: [aqm] [bmwg] first WGLC on draft-ietf-bmwg-traffic

Barry Constantine writes: > Sounds good, we'll include references to netperf-wrapper in the next > version. > > We will also review the common data result format you mentioned and > see how this might fit into the draft. Hi Author of netperf-wrapper chiming in: If you have any questions let me

Re: [aqm] Draft Agenda for IETF91

"Scheffenegger, Richard" writes: > 14:40 > draft-hoeiland-joergensen-aqm-fq-codel > Toke Hoeiland-Joergensen > 20 min I managed to botch the submission process for the update to this, and now the ietf web site is closed for submissions. So until it reopens during the meeting, here is the -0

Re: [aqm] analysis paper on PIE...

"Scheffenegger, Richard" writes: > I believe these papers may qualify that requirement: I'll add to that the results I presented yesterday in ICCRG: http://www.ietf.org/proceedings/91/slides/slides-91-iccrg-4.pdf However, I don't believe there has been any *theoretical* analysis of either alg

Re: [aqm] draft-hoeiland-joergensen-aqm-fq-codel

"Scheffenegger, Richard" writes: > * adopt the document draft-hoeiland-joergensen-aqm-fq-codel-01 as an > AQM working group item, heading towards publication as informational. Well I'm obviously in favour ;) Still being fairly new to this process, however, could someone please explain to me the

Re: [aqm] Gathering Queue Length Statistics

Mikael Abrahamsson writes: > I don't know how the Linux AQM system works, but exposing some of > these counters through the proc subsystem (or something else), might > work, and then a userspace daemon could poll this data as often as it > wanted, then you don't even need the kernel to do averagi

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

Hi Andrea > 1. Besides the results in Toke’s ICCRG presentation at IETF 91 in > November 2014 > (http://www.ietf.org/proceedings/91/slides/slides-91-iccrg-4.pdf), > where can I find other comprehensive comparisons of AQM > implementations for Linux (or any other non-simulated system that > handles

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

"Francini, Andrea (Andrea)" writes: > CoDel's effort to limit the queuing delay appears well motivated when > there is only one queue (e.g., to shield VoIP from the delay induced > by bulk-transfer or video traffic), but when multiple queues are > available the net gain of the effort is unclear.

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

"De Schepper, Koen (Koen)" writes: > Reporting the self inflicted delay on greedy flows might be a good > measurement to additionally report in the test suites, so its impact > on greedy interactive applications can be estimated. Some sort of greedy real-time media or equivalent is definitely mi

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

Simon Barber writes: > One problem with fair queueing is that it can be gamed. By opening > multiple flows you achieve unfair priority. Part of Codel or PIE's > beauty is that they are blind to the traffic, only reacting to the > externally visible characteristics. This stems from the question 'w

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

David Lang 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 counting hash col

Re: [aqm] FQ-PIE kernel module implementation

"Fred Baker (fred)" 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... the codel a

Re: [aqm] FQ-PIE kernel module implementation

Polina Goltsman writes: > As I understand the FQ-Codel draft, it seems to be fundamental to > FQ-Codel that each queue has separate state variables. So my question > is: is it indeed fundamental ? I suppose that becomes a matter of semantics: What exactly do you mean by 'fundamental'. If you mea

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 6.2): http://www.sciencedirect.com/sc

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

"Bless, Roland (TM)" writes: > 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 increa

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 would otherwise work just > fi

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] A question regarding the latest FQ-CoDel Internet-Draft

Rasool Al-Saadi writes: > My question is: Why if we get a packet back, we should _always_ move > the queue to the end of the old queues list? I wonder whether this is > intended or there is an editing error as the previous versions of > fq-codel Internet Drafts do not include this movement. You'

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

Toke Høiland-Jørgensen writes: > Will update the text to make this clearer. Well spotted! :) Updated version is here: https://kau.toke.dk/ietf/draft-ietf-aqm-fq-codel-04.html Also substituted 'credit' for 'deficit' in the text, to make it clearer what is going on con

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 'credit', so just punted

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

Björn Grönvall writes: > This is definitely confusing and even Varghese (one of the DRR authors) uses > this analogy: > > A banking analogy motivates the solution. Each flow is given a quantum, > which is like a periodic salary that gets credited to the flow’s bank > account on every

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 some rough edges > (e.

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 nothing blocking. Hi Spencer Tha

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] Alia Atlas' No Objection on draft-ietf-aqm-fq-codel-05: (with COMMENT)

"Alia Atlas" writes: > -- > COMMENT: > -- > > I think it would be useful to have a reference to the Linux > implementation ("current" version and pointer). Hi A

Re: [aqm] Benoit Claise's No Objection on draft-ietf-aqm-fq-codel-05: (with COMMENT)

"Benoit Claise" writes: > -- > COMMENT: > -- Hi Benoit Thank you for your comments. An updated version that addresses them as laid out below is available here:

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]. [LINUXSRC]? [SRC]? Figured the

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 believe it to > be > a si

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 good, so get on with

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 attempt to be slightly le

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 back on the recommendat

[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, b

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 >> current draft me

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] I am setting up a per holiday cron job

Jana Iyengar writes: > As Wes responded, we're working out the bits of code and the license > in the draft. We have resolution, and I need to get a revised draft to > the AD with some changes in. Sooo... how's it going with that? ;) -Toke ___ aqm mai

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] 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)

Toke Høiland-Jørgensen writes: > Jana Iyengar writes: > >> Yup, coming up next week. > > Or maybe this week? ;) So, any chance of getting this submitted before the cutoff date on Monday? -Toke ___ aqm mailing list aqm@ietf.org ht

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

Jana Iyengar writes: > ... draft-ietf-aqm-codel-08 > is finally posted. This > new version addresses all IESG comments during IESG review, in addition to > review comments by Patrick Timmons and Yoav Nir. We thank everyone for > their help with r

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

Mirja Kühlewind writes: > Do I get gifts as well if I delay the final publication for long > enough now...? ;-) I fear what we got for Jana was the last items on the gift shop's "thank you for delaying our draft" shelf. But I do believe there were a couple of items left on the "thank you for exp

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] 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 -Toke