Alissa Cooper has entered the following ballot position for draft-ietf-aqm-recommendation-09: 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 http://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: http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the hard work on this document. I have a few comments below. -- General: I think it would be useful to define "network devices" up front, and in particular to clarify whether endpoint devices are subsumed in this category. Are the recommendations in this document meant to apply to queues in tablet/smartphone/laptop OSes as well as in routers, switches, etc.? -- Sec 1.2: "instead it provides recommendations on how to select appropriate algorithms and recommends that algorithms should be used that a recommended algorithm is able to automate any required tuning for common deployment scenarios." Seems like there are some extra words here. -- Sec 3: "There is a growing set of UDP-based applications whose congestion avoidance algorithms are inadequate or nonexistent (i.e, a flow that does not throttle its sending rate when it experiences congestion). Examples include some UDP streaming applications for packet voice and video, and some multicast bulk data transport. If no action is taken, such unresponsive flows could lead to a new congestion collapse. Some applications can even increase their traffic volume in response to congestion (e.g. by adding forward error correction when loss is experienced), with the possibility that they contribute to congestion collapse." Would be nice to have a citation or two in this paragraph (though I can see why you might not want to). "Lastly, some applications (e.g. current web browsers) open a large numbers of short TCP flows for a single session. This can lead to each individual flow spending the majority of time in the exponential TCP slow start phase, rather than in TCP congestion avoidance. The resulting traffic aggregate can therefore be much less responsive than a single standard TCP flow." I note that HTTP/2 is on its way to publication and there are a large number of existing implementations, so the characterization of "current web browsers" seems a bit off. I would suggest something like "(e.g. web browsers primarily supporting HTTP 1.1)." -- Sec 7: I think there's actually a really important privacy aspect that should be called out here, which is that by virtue of recommending that AQM algorithms not be dependent on specific transport or application behaviors, network devices need not gain insight into upper layer protocol information for the purpose of supporting AQM. That is, the document's explicit recommendation for algorithms to be able to operate in a transport- and application-agnostic fashion is a privacy-enhancing feature. -- Sec 9: I'm a little surprised that almost all of the research referenced in this document is from the 1990s, given recent attention that has been paid to this topic. _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
