This is the example-rewrite of Sections 1 through 3 I provided to
Wes. There would be other changes to other sections (though I'm not
pushing for any in particular right now).
It includes the majority of new text from version -05, but not
any changes since then.
The idea is simply to explicitly reference 2309 for any text which
was copied from it. I didn't attempt to cover every small wording
change -- these would require explaining the context of the change,
and IMHO are better covered by explicit statements of the reason
for such changes. I'd be happy to see text for cases where someone
thinks that change is needed as background for our recommendations,
not just as an improvement to the text of 2309.
Feel free to comment on what's missing (other than changes since
version -05).
*************************** cut here ***************************
1. Introduction
RFC 2309 introduces the concept of "Active Queue Management" and
describes one AQM algorithm. Since 1998, other AQM algorithms
have come into use. This document updates RFC 2309 where needed,
and gives recommendations for future AQM algorithms.
Section 3 of RFC 2309 describes Random Early Detection ("RED").
Similar algorithms are specified for other non-TCP transports.
RFC 2309 makes recommendations for "routers." Today these same
recommendations apply to a number of other network devices,
including switches, tunnel endpoints, Network Address Transform
("NAT") devices, and other middleboxes, which pass packets,
whether unchanged or modified, into outgoing queues.
A number of AQM procedures are described in the literature
with different characteristics. This document does not
recommend any of them in particular, but does make
recommendations that ideally would affect the choice of
procedure used in a given implementation.
Methods such as congestion exposure (ConEx) [RFC6789] offer a
framework [CONEX] that can update network devices to alleviate
the effects of unresponsive flows.
The discussion in this memo applies to "best-effort" traffic, which
is to say, traffic generated by applications that accept the
occasional loss, duplication, or reordering of traffic in flight. It
also applies to other traffic, such as real-time traffic that can
adapt its sending rate to reduce loss and/or delay. It is most
effective when the adaption occurs on time scales of a single Round
Trip Time (RTT) or a small number of RTTs, for elastic traffic
[RFC1633].
[RFC2309] resulted from past discussions of end-to-end performance,
Internet congestion, and Random Early Discard (RED) in the End-to-End
Research Group of the Internet Research Task Force (IRTF). This
update results from experience with this and other algorithms, and
the AQM discussion within the IETF[AQM-WG].
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. The Need For Active Queue Management
Active Queue Management (AQM) is a method that allows network devices
to control the queue length or the mean time that a packet spends in
a queue. Although AQM can be applied across a range of deployment
enviroments, the recommendations in this document are directed to use
in the general Internet. It is expected that the principles and
guidance are also applicable to a wide range of environments, but may
require tuning for specific types of link/network (e.g. to
accommodate the traffic patterns found in data centres, the
challenges of wireless infrastructure, or the higher delay
encountered on satellite Internet links).
Section 2 of RFC 2309 discusses "tail drop" -- dropping the
most-recently-received packet, as well as "drop front on
full" and "random-drop-on-full". The reader may wish to review
that Section.
Congestion control, like other end-to-end mechanisms, introduces
a control loop between hosts. Sessions that share a common network
bottleneck can therefore become synchronised, introducing
periodic disruption (e.g. jitter/loss). "lock-out" is often also
the result of synchronization or other timing effects.
AQM can be combined with a scheduling mechanism that divides
network traffic between multiple queues (Section 2.1).
The probability of network control loop synchronisation can be
reduced by introducing randomness in the AQM functions used by
network devices that trigger congestion avoidance at the sending
host.
2.1. AQM and Multiple Queues
A network device may use per-flow or per-class queuing with a
scheduling algorithm to either prioritise certain applications or
classes of traffic, or to provide isolation between different traffic
flows within a common class. For example, a router may maintain per-
flow state to achieve general fairness by a per-flow scheduling
algorithm such as various forms of Fair Queueing (FQ) [Dem90],
including Weighted Fair Queuing (WFQ), Stochastic Fairness Queueing
(SFQ) [McK90] Deficit Round Robin (DRR) [Shr96] and/or a Class-Based
Queue scheduling algorithm such as CBQ [Floyd95]. Hierarchical
queues may also be used e.g., as a part of a Hierarchical Token
Bucket (HTB), or Hierarchical Fair Service Curve (HFSC) [Sto97] .
These methods are also used to realise a range of Quality of Service
(QoS) behaviours designed to + meet the need of traffic classes (e.g.
using the integrated or differentiated service models).
Using a combination of AQM and scheduling between multiple
queues has been shown to offer good results in experimental and
some types of operational use.
2.2. AQM and Explicit Congestion Marking (ECN)
An AQM method may use Explicit Congestion Notification (ECN)
[RFC3168] instead of dropping to mark packets under mild or moderate
congestion. ECN-marking can allow a network device to signal
congestion at a point before a transport experiences congestion loss
or additional queuing delay [ECN-Benefit]. Section 4.2.1 describes
some of the benefits of using ECN with AQM.
2.3. AQM and Buffer Size
It is important to differentiate the choice of buffer size for a
queue in a switch/router or other network device, and the
threshold(s) and other parameters that determine how and when an AQM
algorithm operates. One the one hand, the optimum buffer size is a
function of operational requirements and should generally be sized to
be sufficient to buffer the largest normal traffic burst that is
expected. This size depends on the number and burstiness of traffic
arriving at the queue and the rate at which traffic leaves the queue.
Different types of traffic and deployment scenarios will lead to
different requirements.
AQM frees a designer from having to the limit buffer space to achieve
acceptable performance, allowing allocation of sufficient buffering
to satisfy the needs of the particular traffic pattern. On the other
hand, the choice of AQM algorithm and associated parameters is a
function of the way in which congestion is experienced and the
required reaction to achieve acceptable performance. This latter
topic is the primary topic of the following sections.
3. Managing Aggressive Flows
Section 4 of RFC 2309 discusses the management of aggressive flows.
Since RFC 2309 was written in 1998, the concept of "TCP-friendly"
has generally replaced the concept of "TCP-compatible."
In this document a flow is known as "TCP-friendly" when it has a
congestion response that approximates the average response expected
of a TCP flow. One example method of a TCP-friendly scheme is the
TCP-Friendly Rate Control algorithm [RFC5348]. In this document, the
term is used more generally to describe this and other algorithms
that meet these goals.
A TCP-friendly flow responds to congestion notification within a
small number of path Round Trip Times (RTT), and in steady-state
it uses no more capacity than a conformant TCP running under
comparable conditions (drop rate, RTT, packet size, etc.).
The User Datagram Protocol (UDP) [RFC0768] provides a minimal,
best-effort transport to applications and upper-layer protocols
(both simply called "applications" in the remainder of this
document) and does not itself establish a degree of fairness [RFC5405].
Some applications (e.g. current web browsers) open a large
number of short TCP flows for a single session. This can
lead to each individual flow spending the majority of time in the
exponential TCP slow start phase, rather than in TCP congestion
avoidance. The resulting traffic aggregate can therefore be much
less responsive than a single standard TCP flow.
An RTP/UDP video flow that uses an adaptive codec but responds
incompletely to indications of congestion or responds over an
excessively long time period may not be responsive to congestion
signals in a timeframe comparable to a small number of end-to-end
transmission delays. However, over a longer timescale, perhaps
seconds in duration, they con moderate their speed, or increase
their speed if they determine capacity to be available.
Tunneled traffic aggregates carrying multiple (short) TCP flows
can be more aggressive than standard bulk TCP. Applications
(e.g. web browsers and peer-to-peer file-sharing) have exploited
this by opening multiple connections to the same endpoint.
*************************** cut here ***************************
--
John Leslie <[email protected]>
Fred Baker (fred) <[email protected]> wrote:
> From: "Fred Baker (fred)" <[email protected]>
> To: "[email protected]" <[email protected]>
> CC: Wesley Eddy <[email protected]>, John Leslie <[email protected]>
> Subject: Re: [aqm] Obsoleting RFC 2309
> Date: Wed, 2 Jul 2014 19:36:11 +0000
>
>
> 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.
> >>
> >> 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
> >> - 2309 is a bit RED-centric, and we now think that people should
> >> be looking at things other than RED
> >>
> >> 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
> >>
> >> Please share any thoughts you have on this, and what should be done.
> >
> > I?ll give you my view, which I just gave you privately.
> >
> > The changes that have been requested include at least:
> > - remove the word ?RED? from the document. The operators find RED
> > difficult to use and as a result don?t turn it on. They would like
> > alternative algorithm(s) that require at most minimal parameterization,
> > ideally none at all.
> > - add ECN
> > - add scheduling, which 2309 explicitly didn?t address
> > - update references
> >
> > We also have discussed additional recommendations beyond ?everyone deploy
> > RED? and ?we need more research?.
> >
> > 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?.
>
> Gorry, Wesley, Richard, John, and I have been having a fairly lively
> conversation in private mail. 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
> email exchanges, but edited to make them make sense in the present context.
>
> --------------------------------------------------------------------------------
> 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.
>
> 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."
>
> 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.
>
> 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. But I was setting out
> to implement the protocol defined in RFC 793, TCP. Those documents updated
> 793.
>
> 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.
> --------------------------------------------------------------------------------
> If I understand him correctly, one of the things John is pushing back on is
> obsoleting RED as an algorithm; his view, if I understand it, is that if you
> can figure out what parameters to give RED, it works just fine. 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.
>
> 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. 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). 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.
>
> 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.
>
> 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.
> 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. What we *are* trying to do is reduce queuing delay and by extension
> that component of end to end latency.
>
> And it turns out that there are now better algorithms than RED.
>
> 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. 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. The other is so that everyone agrees on what
> an algorithm does, why it does it,
and where it should be implemented. 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.
>
> 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. 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.
> --------------------------------------------------------------------------------
> 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. There has been
> ongoing research since 2309 was written, but a large portion of the relevant
> research predates and is reported in 2309. So we have been asked for an
> updated bibliography in this document, and the updates haven't been as large
> as one might expect from an active research field. I think John would like to
> continue to point to 2309's description of the motivating and underlying
> research.
>
> 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. 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.
> 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. 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.
> draft-geib-tsvwg-diffserv-intercon, for exa
mple, 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.
>
> 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.
> --------------------------------------------------------------------------------
>
> 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. This document, plus the set of algorithms that we wind up
> recommending,are a complete replacement. So I don't see it as an update. I
> see it as making 2309 "historical" or "obsoleted by" this document.
>
> --------------------------------------------------------------------------------
>
> 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.
>
> 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, 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.
>
>
>
>
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
