Alia Atlas <akat...@gmail.com> writes: > Hi Mirja, > > Thanks for the information. I completely agree that it is up to the > authors, shepherd & WG Chairs as to what > clarity to add.
There seems to be consensus on moving 5 to 2 and a few nits worth fixing - but I'm not an author of the codel draft. > On the standards track not being required due to not needing > interoperability with at the same time not enough > deployment, I do think that having a clear statement would help At the time these documents were semi-final (going on 3 years back) it didn't seem like pursuing standards track was the right idea. We still do not have enough deployment data on enough underlying media types - so far we have decent data on cable modems, ethernet, and now wifi. Could use an LTE enodeb and MPLS implementation, at least. > encourage that deployment. Otherwise, it's a > catch-22. I also don't know if codel or fq-codel is actually > preferable and the reasoning - but I haven't gone and I don't know of any pure codel deployments, what's in the third generation in the field is all fq_codel based, with a little bit of uptake of cake[1] with january's "lede-project" release. still waiting for the first pie based cable modems to appear. still hoping we see more than middle tier vendors than ubnt move forward. Codel's ideas do apply independently to all sorts of queue management problems, not just packets per se', and it seems hard enough to wedge them into a standalone draft. > reread the latter. For this work, where the deployment has real > hardware (ASIC, etc) consequences with long > lead-times, being clearer would help. Well, what I know of the initial fpga attempt - one company went under, another went dark. There's some work that may apply (soon) in cambridge's netfpga project. Certainly hope that there is HW IP in progress! There's plenty of time to standardize, and it seems like a great jump to move from experimental to standards track. On the fq_codel front, we found it advantagous to add a bulk dropper last year[2], and we learned a lot from the fq_codel on wifi effort [3], and recently made a nice fix for locally terminated vpns[4]. Given how long the process has taken I've thought about pulling the fq_codel draft and adding in the insights from those efforts... (but that has been stuck behind the codel draft for 2 years in NEEDREF, review was all done). As it will take another year or two to get back decent data from the field on the wifi front, I think getting out the fq_codel draft as it is, is just fine, and 3 or so more years more we can go *.bis on everything. If there is any one thing I'd like to re-add to the aqm lists' workload it is the standard need for something like "BQL" to manage underlying ring buffers better, as that was the core technology that made doing any level of aqm on high speed ethernet possible. [1] https://www.bufferbloat.net/projects/codel/wiki/CakeTechnical/ [2] Bulk dropping and dequeuing: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=9d18562a227874289fda8ca5d117d8f503f1dcca https://lwn.net/Articles/692399/ [3] "Ending the Anomaly - Achieving Low Latency and Airtime Fairness in WiFi" Toke Høiland-Jørgensen, Michał Kazior, Dave Täht, Per Hurtig, Anna Brunstrom https://arxiv.org/abs/1703.00064 [4] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=264b87fa617e758966108db48db220571ff3d60e > > It's nice to see this work moving ahead. > > Regards, > Alia > > On Thu, Apr 13, 2017 at 6:34 AM, Mirja Kuehlewind (IETF) > <i...@kuehlewind.net> wrote: > > Hi Alia, > > thanks for your feedback! Just on your first point regarding the > status. The working group felt that there was not enough > deployment to go directly to standards track and given AQM > algorithm don’t need interoperability it was not really important > for them to go to standards track right away. However, I leave it > to the authors if they are able to add more text on how > experimentation should be further performed. > > Mirja > > > > > > > Am 13.04.2017 um 07:28 schrieb Alia Atlas <akat...@gmail.com>: > > > > Alia Atlas has entered the following ballot position for > > draft-ietf-aqm-codel-07: Yes > > > > When responding, please keep the subject line intact and reply > to all > > email addresses included in the To and CC lines. (Feel free to > cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found > here: > > https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ > > > > > > > > - > --------------------------------------------------------------------- > > > COMMENT: > > - > --------------------------------------------------------------------- > > > > > Thank you for a clear and very well written document. This was > well > > worth staying up > > past 1am to read fully. I do have one primary comment and a > couple minor > > points. > > > > First, the document status is Experimental. While encouraging > > experimentation, the > > document doesn't really articulate what the concerns are or how > > experimentation might > > determine that this should be changed to standards track. While > > regrettably I haven't > > personally followed the AQM work, I might assume that some of > the issues > > to general > > applicability might be tied to aspects around the challenges of > applying > > CoDel to a > > system architecture built around WRED AQM and enqueue complexity > rather > > than dequeue > > complexity. Having a paragraph that gave context in the > introduction for > > the questions > > still to be explored would be helpful. > > > > a) In Sec 3.4 : "This property of CoDel has been exploited in > > fq_codel [FQ-CODEL-ID], which hashes on the packet header fields > to > > determine a specific bin, or sub-queue, for each five-tuple > flow," > > For the general case of traffic, it would be better to focus on > using a > > microflow's > > entropy information - whether that is derived from a 5-tuple, > the IPv6 > > flow label, > > an MPLS Entropy label, etc. Tying this specifically to the > 5-tuple is > > not ideal. > > Obviously I missed this for draft-ietf-aqm-fq-codel-06 - but > even a > > slight rephrasing > > to "for each microflow, identifiable via five-tuple hash, > src/dest + IPv6 > > flow label, or > > other entropy information" would encourage better understanding > of > > micro-flow identification. > > Of course, this is just a comment - so do with it what you will. > > > > b) (Nit) In Sec 5.1: " We use this insight in the pseudo-code > for CoDel > > later in the draft." > > The pseudo-code is actually earlier in the draft. Also > > s/draft/document for publication. > > > > > > > _______________________________________________ > > aqm mailing list > > aqm@ietf.org > > https://www.ietf.org/mailman/listinfo/aqm > > > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
