Wesley Eddy <[email protected]> wrote: > > We didn't receive any comments yet on the updated recommendations > draft, which we were trying to have a working group last call on > per Richard's email to the list on 3/5.
Not sure how I missed that; but alas I did. > Since we think people might not have noticed the last call, we're > re-announcing it. > > In the next two weeks, please review this document: > > https://datatracker.ietf.org/doc/draft-ietf-aqm-recommenda > tion/ > > and relay any comments, questions, corrections, words of support, > etc. to this AQM mailing list. First pass comments: This document is not ready for WGLC. A number of suggestions which seemed headed towards consensus have not been integrated. The questions put to the WG have been too limited, and also too general. We have mostly responded to them as motherhood and apple pie, without enough discussion of the actual wording -- least of all seeking consensus on the underlying principles we're trying to state. We have a number of areas outside of Section 4 which deserve our consideration. The whole "TCP-friendly" terminology is so 1998. ;^) Any meaning it may have had in 1998 has dissipated beyond recovery. We _really_ should come up with another way to say what we mean. I don't see discussion of multiple queues for different flows, which IMHO is necessary for effective Active Queue Management. We haven't discussed the misinterpretation of "congestion collapse". Congestion collapse came from re-transmitting dropped packets. A "non-responsive" flow _cannot_ lead to congestion collapse unless it increases its sending rate in response to congestion (packet drop, usually). It certainly _can_ lead to Denial of Service, but not congestion collapse. For that matter, we don't discuss denial-of-service, which is a very real issue, except for a brief mention in Security Considerations. I don't expect to solve that issue in this document, but I do believe we can say something about how Active Queue Managment might evolve to alleviate denial-of-service problems. (They're alarmingly common today!) Personally, I am not willing to let this document go without _some_ treatment of the issues raised by Bob Briscoe's proposal for "Immediate ECN". I don't mean that we must rubber-stamp Bob's text -- goodness knows I disagree with him about half the time -- but _sometime_ we have to escape the totally irrational belief that ECN can be "the same as" packet drop. (I would suggest placing this in the section 4.2.) In Section 4.2, I have a problem with the glib way we call "delaying packets in flight" a reasonable congestion signal. While I do not deny that some transports use delay as a signal, it's a dreadful signal and should be discouraged for AQMs going forward. (It will still be there as an incidental indicator for a long time; and I don't mean to forbid its use -- merely to encourage other mechanisms instead.) I'd like to see a presentation of how the services expected of the Internet have evolved: that we are now dominated by interactive uses, from web-browsing all the way to real-time conferencing. This will make it clear _why_ it's important to have a way to minimize delay; and will inform discussion of how to make the Internet more responsive to web-browsing while at the same time serving real-time speech. As I said, these are first-pass comments. I'll stop here. -- John Leslie <[email protected]> _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
