Just to keep people on the same page, the latest version is -06. > Fred Baker (fred) <f...@cisco.com> wrote: >> On Jul 1, 2014, at 5:24 PM, Fred Baker (fred) <f...@cisco.com> wrote: >> >> As I said yesterday, I am scratching my head on what it means to >> "obsolete" or "update" a document, and how that might relate to this >> note. > > Fred is not alone! The IESG keeps coming back to that! > I think we need AD advice on this.
>> To my small mind, if I have a specification that updates another >> specification, I have to read the older specification, and then >> I have to read the newer one and do what it says in the part of the >> older that it updates. If one specification has obsoleted another, >> the older specification is only of historical interest. >> >> When I said that in private email, John replied >> "That is correct -- iff you are setting out to implement the older >> spec." > > Exactly. If you are implementing the newer spec, you have to read > the older one if, and only if, it is listed among the Normative > References. > > At the time I wrote that, it didn't occur to me that anyone today > would be told to "implement 2309". > >> The only reason I would have to not implement the older spec is if >> it were obsolete. It is was merely updated, I am by definition >> implementing the older spec, with some changes. > > This confused me at the time... It still confuses me. > >> Let me give you an example. If I decide to implement TCP, I start with >> >> https://tools.ietf.org/html/rfc0793 >> 0793 Transmission Control Protocol. J. Postel. September 1981. >> (Format: TXT=172710 bytes) (Obsoletes RFC0761) (Updated by RFC1122, >> RFC3168, RFC6093, RFC6528) (Also STD0007) (Status: INTERNET >> STANDARD) >> >> and also read 1122, 3168, 6093, and 6528. Those clean up some basic >> stuff, add ECN, change Urgent, and add a variant on a SYN Cookie. >> If I don't do those, I haven't got a correct implementation of TCP. > > (Many folks claim to have a "correct implementation of TCP" without > implementing all those. :^( We have no way of policing this -- but we > do from time to time try to produce a TCP-roadmap kind of document.) > >> But I was setting out to implement the protocol defined in RFC 793, >> TCP. Those documents updated 793. > > (TCP, IMHO, is the worst case among RFCs!) > >> However, if I decide to implement >> >> https://tools.ietf.org/html/rfc5681 >> 5681 TCP Congestion Control. M. Allman, V. Paxson, E. Blanton. >> September 2009. (Format: TXT=44339 bytes) (Obsoletes RFC2581) >> (Status: DRAFT STANDARD) >> >> I don't have to read RFC 2581. Everything that was in 2581 that I >> need to know will be found in 5681. I'm only implementing 5681, >> not 2581. I might read it for interest's sake, or as a historian, >> but as an implementor it is unnecessary. > > The same would be true if 5681 merely updated 2581 but didn't list > it as a normative reference. (Of course, if 5681 weren't a DRAFT > STANDARD it might not be succeptible to implementation under those > conditions.) > > But what Fred says is correct. > > It's just that "implementing AQM-REC" has a defined meaning, > while "implementing 2309" is hopelessly vague -- since 2309 mostly > discusses research, and only lists RED as an example. > So this an RFC that is informational, but, t does recommends use of RED as THE way to do AQM. If people support this as the current recommendation - then they should speak, this is not the consensus I hear. >> If I understand him correctly, one of the things John is pushing back >> on is obsoleting RED as an algorithm; > > I am saying that obsoleting RED seems premature. > We've been through this several times, and the new draft does not do this. The intention was to remove the recommendation that RED is THE way to do AQM. >> his view, if I understand it, is that if you can figure out what >> parameters to give RED, it works just fine. > > I'm saying that's a widespread belief. > I'm suggesting this is consistent with the intention of the new document. I for one would be happy to edit if we have a specific proposal of a change. >> On that point, I would generally agree; in my experience, RED has >> two important parameters, which are min-threshold and max-threshold. >> The mean latency through a queue will generally be governed by and >> approximate min-threshold, so one wants to set it just deep enough >> to accomplish ones latency goals, and max-threshold is derived from >> the underlying hardware. > > Yes, but actually my point is that folks are shipping varieties of > RED; and we're unlikely to change that by any classification of 2309. > Indeed - but same point: I do not see what you write as the intention of the new BCP. We are speaking here in my mind about the recommendation that RED is the best current practice. >> However, the operational commentary on RED in twvarea, tsvwg, and >> over time has been that "just deep enough to accomplish ones latency >> goals" is fuzzy enough to be difficult to use. > > I absolutely agree! > >> CoDel was developed, in part, to make the latency goal an explicit >> algorithmic factor; if part of the delay in a transmission system is, >> for example, channel acquisition delay (think about the behavior of >> busy conference WiFi systems), it would be nice to have that factored >> into the calculation as well as actual queue depth (which is >> corollary to but not necessarily indicative of latency). > > I agree on the goals, and agree that CoDel was a step in that > direction. > >> Other algorithms, of which PIE is an example, work with queue depth >> as a corollary to latency, and adjust their understanding of the >> relationship dynamically. > > Agreed. > >> Gorry and I have separately commented, in that private conversation, >> that obsoleting RFC 2309 doesn't obsolete RED as an algorithm, >> nor does it say that RED is a bad algorithm. It replaces the >> recommendation of 2309, which is that >> >> o RECOMMENDATION 1: >> >> Internet routers should implement some active queue management >> mechanism to manage queue lengths, reduce end-to-end latency, >> reduce packet dropping, and avoid lock-out phenomena within the >> Internet. >> >> The default mechanism for managing queue lengths to meet these >> goals in FIFO queues is Random Early Detection (RED) [RED93]. >> Unless a developer has reasons to provide another equivalent >> mechanism, we recommend that RED be used. > > More exactly, AQM-REC replaces that (whether or not 2309 is > obsoleted). > >> 16 years following the publication of RFC 2309, it turns out that we >> have issues, but the issues are not the management of queue lengths, >> reduction of packet dropping, and avoidance of lock-out phenomena >> within the Internet. > > I'm not sure I agree there -- but the problems certainly _have_ > changed and we ought to describe at least some of the changes. > If you do not agree, could you propose new text? >> RED, by the way, never did reduce packet loss; it drops the same >> number of packets, but attempts to desynchronize them and achieve >> a certain goal using them. > > A perfect example of why we want to avoid AQM-REC being 2309bis. > A 2309bis would have to discuss this! > >> What we *are* trying to do is reduce queuing delay and by extension >> that component of end to end latency. > > I completely agree. > >> And it turns out that there are now better algorithms than RED. > > I also agree there -- I'm just not convinced we're ready which > to recommend. > To understand this comment, I think it is useful to know which recommendation(s) you have questions on? >> I would go one step further here, and whether this comment belongs in >> the draft or not is not important to me. There are two reasons one >> might standardize something. The most common one, and the one that >> motivates most IETF work, is interoperability of separate >> implementations that have to communicate. OSPF and IS-IS, for example, >> need to be specified down to the gnat's eyelash, including the >> "alternate Tuesday rules" that make different implementations make >> the same choice when more than one choice could reasonably and >> validly be made, to guarantee interoperability. > > Yes. > >> That consideration doesn't apply here; TCP will interpret signals >> from the network including ECN and packet loss even if the network >> doesn't realize that they are signals. The only requirement that >> could be described using the term "interoperability" is that the >> TCP/SCTP/whatever receiving the signals should as a result do the >> right thing. > > There are bunches of things within TCP where interoperation is > a matter of hoping for the best. :^( But standardizing several of the > possible choices still helps. > >> The other is so that everyone agrees on what an algorithm does, why >> it does it, and where it should be implemented. > > (Fred is an optimist! ;^) > >> BCP 38, for example, can be implemented in several ways, but because >> it is standardized as a recommendation, we know what we are trying >> to achieve when we implement it. > > Yes, even this helps. > >> What we are obsoleting, at minimum, is the recommendation that RED >> be the default algorithm. What we instead recommend is that each >> implementation implement some form of AQM to achieve certain purposes. > > IMHO that's already done, even if we neither obsolete no update 2309. > >> That statement alone could be an update to 2309 if 2309 made its >> recommendation regarding RED in one place. However, it is throughout >> the document. Hence, a change to 2309's statement regarding RED is >> a pervasive change affecting every section of it. > > It doesn't matter how pervasive the change -- it only matters that > the intent of the update is stated clearly enough. > >> The other thing I think John is trying to preserve - and John, I'm >> looking for your correction here - is 2309's report on research. > > I do believe that that report deserves to be preserved. I see no > reason to declare it obsolete. But my concern is that we avoid the > rathole of trying to update it while obsoleting 2309 itself. > Well that I thought was the intention. >> There has been ongoing research since 2309 was written, but a large >> portion of the relevant research predates and is reported in 2309. > > Agreed. > >> So we have been asked for an updated bibliography in this document, > > I'm _really_ tempted to "Just say No!" here. Such an updated > bibliography would indeed be useful, but its utility doesn't depend > on doing it here; and it feels like part of that rathole I want to > avoid. > >> and the updates haven't been as large as one might expect from an >> active research field. > > Are you surprised? > >> I think John would like to continue to point to 2309's description >> of the motivating and underlying research. > > Yes. > >> On that, I go two ways. First, as a historical review of the research >> the original recommendation was based on, 2309 is unsurpassed. >> Second, I think we do need to motivate the updated recommendations >> we make, which include for example the implementation of ECN. For >> that reason, we need to point to at least some research. > > Indeed! But it isn't the same research "updated bibliography" implies. > >> We have been asked, by the proponents of fq_codel, to also mention >> scheduling. 2309 left that out and said why it left that out. > > This is an area for "Send text!" > >> draft-baker-aqm-sfq-implementation is my further reflections on the >> interaction between scheduling, which has to do with the distribution >> of service across competing sessions, and AQM, which has to do with >> latency; they two don't necessarily get along as well with each other >> as one might expect. > > (My expectations were pretty low to start with! ;^) > >> In this document, we have tried to say that we don't have a problem >> with scheduling implementations, but we think AQM might be applied >> differently to different traffic classes in the same queuing system. > > Talking "scheduling" _will_ confuse that CTO... > >> draft-geib-tsvwg-diffserv-intercon, for example, contemplates four >> traffic classes, one of which is engineered to RFCs 3246/3247, >> one of which allows for a shallow queue without AQM for UDP-based >> applications, one of which allows for a deeper queue with AQM for >> "preferred" elastic traffic, and one of which is simply the default >> class, which one might expect AQM in but would bear the brunt of >> traffic loss should it occur. > > I don't think we're prepared to say very much about that... > >> To my mind, we're going quite a bit further than "just remove RED"; >> we are doing things 2309 said it didn't want to do, and adding >> capabilities that 2309 didn't consider. > > And I agree we should be doing that. > >> In any event, RFC 2309 remains in the historical record, which is to >> say the RFC series. It's a great document. But when we send someone >> to figure out what to implement in an AQM implementation, I don't >> think we are going to send them there. > > It would be strange to send anyone to a 16-year-old Individual > Informational RFC instead of an IETF BCP. > >> This document, plus the set of algorithms that we wind up recommending, >> are a complete replacement. > > I don't think AQM-REQ version -05 quite makes it there. And I want > to stop trying. > What about version -06? >> So I don't see it as an update. I see it as making 2309 "historical" >> or "obsoleted by" this document. > > Those are different categories. "Historical" is typically handled by > an IESG management item nowadays. "Obsoleted-by" implies that everything > of current importance is covered in the new document. Personally, I > wouldn't try for that. > > But once AQM-REC is published as a BCP, I certainly wouldn' oppose > an IESG management item to move 2309 to "historic". > >> ---------------------------------------------------------------------------- >> >> Which brings me back to John's proposed text. I'm frankly curious what >> the working group's thought on that is. If the working group wants to >> replace the existing sections 1-3 with that or an updated version of >> that, so be it. I'm willing to see John added as a co-author or >> co-editor and the text dropped in. If the working group prefers the >> existing text, I'm OK with that. If there are glaring holes, they need >> to be filled in. > > (For many years I resisted authoring an RFC; but I won't resist now.) > > "Glaring", I'm afraid, is in the eye of the beholder. I don't mean > to bring up holes in AQM-REC as a 2309bis; but others keep mentioning > them, and they sure look like holes to me. :^( > >> What I'm not OK with is a continuation of the current dinking with >> the document. I don't think we have dramatically improved the document >> since last November, > > I'm mostly with Fred here: I _want_ to stop dinking with it! > >> although we have done a lot of work on it to respond to working group >> comments. It feels to me like we, as a working group, have lost our >> way. From this point on, *I* think we need to ask ourselves whether >> any given change we make materially improves the document or merely >> dinks with the text. And we should limit changes to material >> improvements. > > I mostly agree. That's why I'm proposing a material change in approach, > to greatly reduce the area for dinking. > > -- > John Leslie <j...@jlc.net> > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --- Gorry _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
