Re: [aqm] Obsoleting RFC 2309

[[e-mail]]

Just to keep people on the same page, the latest version is -06.

> Fred Baker (fred) <[e-mail]> wrote:
>> On Jul 1, 2014, at 5:24 PM, Fred Baker (fred) <[e-mail]> 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 <[e-mail]>
>
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm
>
---

Gorry