I, for one, would be very interested to see work done in this area, so count me as one of the infamous "+1". I think a good place to start is a BCP (or multiple, depending on what is to be accomplished), and then from that point consider subsequent related topics. And certainly, we'd want the Ops folks involved, though that brings up the question of whether such an effort should start in Ops first.
Perhaps other questions to bring to the table would be: - would there be a need for a requirements and/or framework document? - does one anticipate signaling (predominantly, intra-domain) to configure AQM nodes to reflect an administrative policy? the downside of the above questions is that they can slow the entire process down and perhaps get us in a situation of lost in introspective thought. On the other hand, they could help provide direction of any potential working group and help bound the problem space. I think the problems still exist in finding the "sweet spot" in determining the right configurations for AQM, and dissiminating this information on a domain-wide basis. -ken On Nov 25, 2012, at 9:56 PM, Wesley Eddy wrote: > Particularly, I have wondered: > - Should we have a working group looking at AQMs? > - If so, does it make sense to shoot for Standards Track > specifications? > - Would we be able to come up with actual requirements > on an AQM so that it's implementable for cheap in > hardware and software, and behaves well under load? > - Would it be valuable to have a test suite for AQMs > similar to what ICCRG was doing for high-rate TCP? > - Would it be valuable to have a BCP (or multiple) on > configuring "legacy AQM" like RED, or the use of AQM > metrics like "sojourn time" rather than variations of > the queue length? > - If any of this is of value, how much belongs in the > ICCRG versus TSV working groups?
