John, Thanks for getting back, this is helpful and I can prepare a new revision to cover the feedback from you and Bob, see below:
[email protected] <[email protected]> wrote: > > If you see ambiguity in "network device", by all means send us propose > text again (I must have missed that detail. You're welcome to my text from July 2: http://www.ietf.org/mail-archive/web/aqm/current/msg00701.html I don't know whether that matches your intent: I have no desire to change your intent. GF: I looked, and didn't find a specific definition. The text in the present draft says (there since -00), which I think is at least a clarification of what was intended: "These mechanisms may be implemented in network devices that include routers, switches, and other network middleboxes." > Apart from that, does this mean you have no specific comments on this > version? If Bob makes any fuss about "congestive collapse" I support him. Otherwise, I make a strong request that you add a definition of that term: I have no idea what you mean that's consistent with what you wrote and the way the Internet works. GF: The present document uses both "congestion collapse" and "congestive collapse". I am OK with you proposal: s/congestive/congestion/g: 4 instances --- I do remain convinced that the charter wording calling for obsoleting RFC 2309 was ill-advised, and is not what this WG actually chose to do. I'd much prefer to fix the charter milestone language; but I detect no enthusiasm for that. I'll settle for being listed "in the rough" in the Shepherd's writeup. My thorough review was of version -05. Since then, I note the change in the Abstract from "updated" to "and replaces these" [recommendations of 2309]. I don't see any particular reason for that change, but won't fuss over it if nobody else cares. GF: This is what I hear was the result of the consensus call by the Chairs when the proposed future status for RFC 2309 was agreed. --- I note the addition of a section header for "1.1 Congestion Collapse" which correctly includes "fix for Internet meltdown"; but I think the switching between "Congestion Collapse" and "congestive collapse" is confusing. ("Congestion Collapse" is a well-defined term of art; and wouldn't need a definiton unless you think you can write one which will make the usage of that term correct in this document.) GF: See above change. --- Most of my comments about version -05 can simply be listed as "ignored" or perhaps "considered and ignored"; but a few never made it onto the list because I thought the change from "obsoletes" to "updates" needed to be discussed first. GF: No No that was not the case - The new text was at least "considered" in some detail, we went through both the text from Wes, your text and others line by line before formulating the new revision. ---- In Section 3 subsection 3, I would prefer that we not perpetuate the idea that flows must be "TCP-friendly". While there are indeed cases of unfriendly-to-TCP flows, that really isn't an AQM issue. GF: I think scheduling and isolation have been discussed within the group, so I personally don't agree with your view that this is out of scope. Although Im no fan of Non-TCP friendly, and would like to replace this with less responsive that TCP. --- In Section 4.6, in talking of "elastic transport congestion control", I fail to see how this relates to AQM; and I'd prefer not jawboning about how transports "should" function. (This sort of text would be entirely proper in an IRTF document; but we're now doing an IETF BCP concerned with queue management in network devices.) GF: Im thinking CC reacts to AQM to reduce the rate. --- Section 4.7 returns to 2309's "need further research" conclusion. It seems to me out-of-place to list these things in a BCP. GF: Others have not said this. --- In Section 8 Acknowledgements, I don't think it correct to say, "This is an edited version of that document". (I agree it started that way, but I find that not an acceptable basis for a BCP.) GF: Indeed, I think we should change this now the document is nearly ready. I propose something more like: NEW: The original version of this document describing best current practice was based on the informational text of [RFC2309]. This was written by the End-to-End Research Group, which is to say Bob Braden, Dave Clark, Jon Crowcroft, Bruce Davie, Steve Deering, Deborah Estrin, Sally Floyd, Van Jacobson, Greg Minshall, Craig Partridge, Larry Peterson, KK Ramakrishnan, Scott Shenker, John Wroclawski, and Lixia Zhang. Although there are important differences, many of the key arguments in the present document remain unchanged from those in RFC 2309. ==== You have every right to say I should have raised these points earlier; but that's a poor substitute for evaluating their merit. It is the intent of a Working Group Last Call to solicit thorough reviews by WG participants -- and follow through on those with merit. The habit of tossing the WGLC comments at the authors and marginalizing any further comments to the authors' response is a bad habit. I wish we would break it. GF: This is more of comment about the IETF contributions, we also in general benefit when there are more WG contributions to calls for inputs, instead of leaving review to during or following of WGLC. However, I personally think all inputs are valuable, if they present ideas for improving a document! -- John Leslie <[email protected]> _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
