Wes and all, My comment is in regard to Polina's comment "The WG currently has two AQMs (dropping/marking policy) in last call. Did someone evaluate these AQMs according to the specified guidelines?". As I read over draft-ietf-aqm-eval-guidelines, I did not think the objective of this memo was to arrive at consensus to select one specific AQM. I thought the objective was to publish guidelines for implementers & service providers on how they can select an AQM that is best for their environment. And further that both AQMs in last call would complete the process as valid AQMs for implementers & service providers as available to use in their environment, with the guidelines helping them to decide which is best for them. Some may chose PIE, some may chose FQ_CODEL. And possibly other future AQMs would go through the IETF process for publication, and that would be an additional option for implementers & service providers to evaluate according to the guidelines as best for their environment.
Is my understand of draft-ietf-aqm-eval-guidelines correct? Regards, Carl Klatsky Comcast From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of Wesley Eddy Sent: Friday, January 22, 2016 9:51 AM To: aqm@ietf.org; Polina Goltsman Subject: Re: [aqm] I-D Action: draft-ietf-aqm-eval-guidelines-09.txt On 12/7/2015 7:32 AM, Polina Goltsman wrote: In the abstract, the document says that it describes characterization guidelines for an AQM proposal, to decide whether it should be adopted by the AQM WG. The WG currently has two AQMs (dropping/marking policy) in last call. Did someone evaluate these AQMs according to the specified guidelines? In my opinion, for "standardization" it would be good to have crisp guidelines. For simply publishing RFCs that are experimental (not standardized), it is much less important. Moreover, it seems to me that the WG is about to conclude. What exactly is the purpose of standardizing this document then ? It's definitely true that the activity level has been low, and so we're trying to wrap up the outstanding work items before it flattens completely. This document is not proposed for standards track, only "Informational". The current goal as I see it (with co-chair hat on) is to see if we have rough consensus that this is a useful contribution to the community going forward, and that any small issues can be addressed. As I understood your review (please correct if I'm wrong), a main issue you see is that there isn't specific guidance about numeric values or ranges to use in evaluations? Nicolas explained why this might be a bit difficult to do in general (and specific values published in 2016 may be moot by 2018), so as I understand, one of the limitations of this document is that it is only going to be able to provide general descriptive guidance in terms of what kinds of tests to run, and what types of things to look for, but not prescriptive values and conditions to be met. Do you think that's okay, even though it's probably less directly useful than if there were specific values?
_______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
