Fred Baker (fred) <[email protected]> wrote: > On Jul 1, 2014, at 5:24 PM, Fred Baker (fred) <[email protected]> wrote: >> On Jul 1, 2014, at 2:27 PM, Wesley Eddy <[email protected]> wrote: >> >>> John Leslie noticed that some of the things Bob Briscoe had >>> mentioned stem from trying to work from RFC 2309 as the starting >>> point. We have been planning to Obsolete and replace 2309 with >>> this document. John suggested instead to let it live on, and >>> have this new one only Update it, and has suggested specific >>> changes that could be edited in, if this were the case.
Briefly, this started with a promise I made to Fred to review aqm-recommendation from the viewpoint of a CTO. I did so, ending up with a heck-of-a-lot of red ink on the document. I noticed that the red ink was heavily concentrated in Sections 1 through 3, which for the most part restated nearly verbatim the language of 2309. Thus I wrote to Wes, asking why we had to "obsolete" 2309 instead of "update" it. >>> I think we need to make a conscious on-list decision about this, >>> and decide to either confirm that Obsoleting 2309 is correct, or >>> to change course. >>> >>> Others can amplify or correct these, but I think the points for >>> each would be: >>> >>> Obsoleting 2309 >>> - 2309 was an IRTF document from a closed RG, and we now can make >>> a stronger statement as an IETF group with a BCP Any BCP we publish will do that. >>> - 2309 is a bit RED-centric, and we now think that people should >>> be looking at things other than RED I agree; but the way to accomplish that is to state it clearly in the BCP we publish, not expect people to guess that's what we meant to do by declaring it obsolete. >>> Not-Obsoleting 2309 (e.g. Updating 2309) >>> - 2309 is a snapshot in history of the E2E RG's thinking >>> - 2309 is mostly oriented towards AQM as a mitigation for congestion >>> collapse, whereas now we're more interested in reducing latency I agree with these, of course... [Fred replied:] >> >> The changes that have been requested include at least: >> - remove the word 'RED' from the document... That wouldn't accomplish what they want -- even if aqm-rec obsoletes 2309. We have to say that RED is no longer recommended. >> The operators find RED difficult to use and as a result don't turn >> it on. I support saying this, in as many words. >> They would like alternative algorithm(s) that require at most >> minimal parameterization, ideally none at all. Likewise. >> - add ECN Likewise. >> - add scheduling, which 2309 explicitly didn?t address This is a bit more difficult, but I'd be glad to see it. >> - update references This sounds like more trouble than it's worth. If we write a 2309bis, we really ought to do it; but I thought we had decided against that. >> We also have discussed additional recommendations beyond >> 'everyone deploy RED' and 'we need more research'. Indeed, we must do that to follow our charter. >> If you count affected lines in the document, just removing the word >> 'RED' affects 154 of the 955 lines in the document. Then we go into >> the rest of the changes. I'm not sure in what way that can be >> described as an 'update'. Fred makes my point: trying for a 2309bis by blindly making those changes proves to be completely impractical. Thus, I supplied Wes with an example of a rewrite of Sections 1 through 3 that referred to 2309 as an Informative Reference to lay the background for what we actually recommend. I'll post that to the list separately: it's a bit long-winded, but nowhere nearly as long-winded as the current Sections 1 through 3; and IMHO it's quite a bit easier for a CTO to read. > Gorry, Wesley, Richard, John, and I have been having a fairly lively > conversation in private mail.i I quite agree with Fred that this deserves to go on-list. And I give Fred 100% permission to quote anything I wrote (with a possible exception for where I was quoting someone else). > Let me pull out of it a few comments I have made. John can make his > points, and others can make theirs. Note that the following are not, > properly speaking, forwarded email; they are taken from emaili > exchanges, but edited to make them make sense in the present context. > > ------------------------------------------------------------------------------ This seems like a good point to break: we're already over 100 lines. I promise to come back to this right after posting my example Sections 1 through 3. -- John Leslie <[email protected]> _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
