Re: [aqm] Obsoleting RFC 2309

[John Leslie <[e-mail]>]

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!

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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]>