Subject: [aqm] Obsoleting RFC 2309

From: Wesley Eddy <[email-masked]>
Date: Tue, 01 Jul 2014 17:27:28 -0400

There has been a bit of discussion last week about
draft-ietf-aqm-recommendation and how to improve the text near
the beginning, that leads to and sets context for the actual
recommendations.

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.

-- 
Wes Eddy
MTI Systems

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 2 Jul 2014 00:24:44 +0000

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

Note that I’m not arguing that John’s calling my baby ugly. He is, but that’s another matter :-). He sent you some proposed text to replace sections 1-3, which I think the working group needs to see, as that’s the text you’re calling an “update” as opposed to “obsoleting” the document. If the consensus is to replace the existing sections 1-3 with his text, so be it. But it’s still a huge change from 2309. Since one doesn’t have to read 2309 to understand this document, I don’t see how it’s an “update”.

---

From: "Akhtar, Shahid (Shahid)" <[email-masked]>
Date: Wed, 2 Jul 2014 16:07:50 +0000

Hi Wes,

Can you share the update/text that John Leslie had suggested which Fred mentions in his comment.

Thanks,

-Shahid.

-----Original Message-----
From: aqm [mailto:[email-masked]] On Behalf Of Wesley Eddy
Sent: Tuesday, July 01, 2014 4:27 PM
To: [email-masked]
Subject: [aqm] Obsoleting RFC 2309

There has been a bit of discussion last week about draft-ietf-aqm-recommendation and how to improve the text near the beginning, that leads to and sets context for the actual recommendations.

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

--
Wes Eddy
MTI Systems

_______________________________________________
aqm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/aqm

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 2 Jul 2014 19:10:03 +0000

> Can you share the update/text that John Leslie had suggested which Fred mentions in his comment.

I have attached the text John sent yesterday. It is derived from -05. I *think* he would like to replace sections 1-3 of draft-ietf-aqm-recommendations with the content of that text, and then reconsider the additional text in -06 to see if it is still required and if so where it might go.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 2 Jul 2014 19:36:11 +0000

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

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

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.

---

From: John Leslie <[email-masked]>
Date: Wed, 2 Jul 2014 16:43:56 -0400

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

>>> a stronger statement as an IETF group with a BCP

   Any BCP we publish will do that.

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

>>> collapse, whereas now we're more interested in reducing latency

   I agree with these, of course...

[Fred replied:]
>> - 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-masked]>

---

From: John Leslie <[email-masked]>
Date: Wed, 2 Jul 2014 16:54:48 -0400

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-masked]>
Fred Baker (fred) <[email-masked]> wrote:
> From: "Fred Baker (fred)" <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> CC: Wesley Eddy <[email-masked]>, John Leslie <[email-masked]>
> Subject: Re: [aqm] Obsoleting RFC 2309
> Date: Wed, 2 Jul 2014 19:36:11 +0000
> 
> 
> > I?ll give you my view, which I just gave you privately.
> > 
> >    - 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
> > 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?.
>

---

From: John Leslie <[email-masked]>
Date: Wed, 2 Jul 2014 18:03:13 -0400

Fred Baker (fred) <[email-masked]> 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.

> 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!)

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

   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.

---

From: [email-masked]
Date: Thu, 3 Jul 2014 08:54:54 +0100

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

>    Fred is not alone! The IESG keeps coming back to that!
I think we need AD advice on this.

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

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

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

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

> changed and we ought to describe at least some of the changes.
If you do not agree, could you propose new text?

>    I also agree there -- I'm just not convinced we're ready which
To understand this comment, I think it is useful to know which
recommendation(s) you have questions on?

> rathole of trying to update it while obsoleting 2309 itself.
Well that I thought was the intention.

>    I don't think AQM-REQ version -05 quite makes it there. And I want
What about version -06?

> to greatly reduce the area for dinking.
---

Gorry

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Jul 2014 09:59:53 +0200 (CEST)

>   I am saying that obsoleting RED seems premature.

The first thing that came to my mind, is that recommending RED is 
something I would like to stop doing, instead I would like to recommend 
something else. What this means in terms of status of 2309, I have no 
idea.

For instance 7141 updates 2309, if we obsoleted 2309, what would that mean 
to 7141?

> RED; and we're unlikely to change that by any classification of 2309.

My thinking here was that people perhaps could stop implementing RED when 
they do new products, so in 2020 an implementor feels no need to implement 
RED-functionality, but instead only implements whatever we come up with 
here. By doing a BCP, I think we would achieve that?

> an IESG management item to move 2309 to "historic".

Sounds reasonable.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 3 Jul 2014 08:15:41 +0000

On Jul 3, 2014, at 12:59 AM, Mikael Abrahamsson <[email-masked]> wrote:

> For instance 7141 updates 2309, if we obsoleted 2309, what would that mean to 7141?

Well, for one thing, it affects one of -06’s references. Oops

>    [Byte-pkt]
>               and Internet Engineering Task Force, Work in Progress,
>               "Byte and Packet Congestion Notification (draft-ietf-
>               tsvwg-byte-pkt-congest)", July 2013.

should point to 7141. It’s a normative reference. We also carried the recommendation into the draft:

> 4.4.  AQM algorithms SHOULD respond to measured congestion, not
>       application profiles.
> 
> ...
> 
>    An AQM algorithm should not deliberately try to prejudice the size of
>    packet that performs best (i.e.  Preferentially drop/mark based only
>    on packet size).  Procedures for selecting packets to mark/drop
>    SHOULD observe the actual or projected time that a packet is in a
>    queue (bytes at a rate being an analog to time).  When an AQM
>    algorithm decides whether to drop (or mark) a packet, it is
>    RECOMMENDED that the size of the particular packet should not be
>    taken into account [Byte-pkt].

That was a pretty early change - I think in the initial set of recommendations I proposed.

We might, however, need to rethink the wording there. What we’re trying to say, following 7141, is that one shouldn’t try to target data packets or some such thing. A packet is a packet; if the time comes to hit one, hit the one you’re looking at. But now that I read it, I could imagine someone thinking that means we can’t measure bit rates, only packet rates. Mumble.

---

From: John Leslie <[email-masked]>
Date: Thu, 3 Jul 2014 13:11:27 -0400

> something else. What this means in terms of status of 2309, I have no 

   There are several different ways to accomplish this, but basically,
_any_ BCP we publish will trump that recommendation of 2309.

   I merely am recommending that we state our intent clearly.

> For instance 7141 updates 2309, if we obsoleted 2309, what would that mean 

   Although I'm pretty familiar with 7141, I wanted to re-read it before
responding. It's not an easy read, at 41 pages, largely in academic-paper
style. (In fact, this reading did nothing to change my answer, but I'm
cautious about such things.)

   7141 is tolerably clear about what portion of 2309 it "updates" and
it lists 2309 in its Normative References.

   As phrased, Mikael's question asks what would be different if AQM-REC
_obsoletes_ rather than _updates_ 2309 -- with respect to interpretation
of 7141 itself.

   The answer to that question is: most likely no difference at all.

   A Normative Reference, by definition, is something which must be
read to understand the RFC referencing it. This need-to-read survives
any future classification of the referenced RFC to obsolete or historic.

   There's a separate question (not asked) of what it would mean if
AQM both obsoleted 2309 and listed it as a Normative reference. This
is not fully-settled: I believe the RFC Editor tries to avoid such
cases.

> here. By doing a BCP, I think we would achieve that?

   Actually, IMHO, we'd achieve that even if we never mentioned 2309
at all. But it is clearly easier for future implementors if we state
that intent clearly in AQM-REC, regardless of metadata about "update",
"obsolete", or "historic", which are after all merely aids to readers:
not part of the RFCs themselves.

---

From: John Leslie <[email-masked]>
Date: Thu, 3 Jul 2014 13:22:45 -0400

Fred Baker (fred) <[email-masked]> wrote:
> 
> ... We also carried the recommendation into the draft:
> 
> We might, however, need to rethink the wording there. What we're trying
> to say, following 7141, is that one shouldn't try to target data packets
> or some such thing. A packet is a packet; if the time comes to hit one,
> hit the one you're looking at.

   That's the way I read it...

> But now that I read it, I could imagine someone thinking that means we
> can't measure bit rates, only packet rates. Mumble.

   I can't see that interpretation as reasonable, given the phrase
] (bytes at a rate being an analog to time).

   It would be possible for someone to argue that restating a recommendation
from another document weakens both statements; but I disagree: We should
clearly state what we mean in this document, and I believe this wording
does so.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 14 Jul 2014 07:05:50 +0000

> clearly state what we mean in this document, and I believe this wording

The argument for putting it in there started from the fact that we are obsoleting 2309, as stated in the charter. I would understand a document that updates 2309 to be in a strange state if 2309 is itself made historic or obsolete. So we carried the recommendation into this document so it wouldn’t get lost.

---

From: "Akhtar, Shahid (Shahid)" <[email-masked]>
Date: Mon, 14 Jul 2014 18:08:55 +0000

Hi Fred, All,

Let me an additional thought to this issue.

Given that (W)RED has been deployed extensively in operators' networks, and most vendors are still shipping equipment with (W)RED, concern is that obsoleting 2309 would discourage research on trying to find good configurations to make (W)RED work.

We had previously given a presentation at the ICCRG on why RED can still provide value to operators (http://www.ietf.org/proceedings/88/slides/slides-88-iccrg-0.pdf). We have a paper at Globecom 2014 that explains this study much better, but I cannot share a link to it until the proceedings are available.

One of the major reasons why operators chose not to deploy (W)RED was a number of studies and research which gave operators conflicting messages on the value of (W)RED and appropriate parameters to use. Some of these are mentioned in the presentation above. 

In it we show that the previous studies which showed low value for RED used web traffic which had very small file sizes (of the order of 5-10 packets), which reduces the effectives of all AQMs which work by dropping or ECN marking of flows to indicate congestion. Today's traffic is composed of mostly multi-media traffic like HAS or video progressive download which has much larger file sizes and can be controlled much better with AQMs and in our research we show that RED can be quite effective with this traffic, with little tuning needed for typical residential access flows.

Prefer John's proposal of updating 2309 rather than obsoleting, but if we can have some text in Fred's draft acknowledging the large deployment of (W)RED and the need to still find good configurations - that may work. I can volunteer to provide that text.

-Shahid.

-----Original Message-----
From: aqm [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
Sent: Monday, July 14, 2014 2:06 AM
To: John Leslie
Cc: [email-masked]
Subject: Re: [aqm] Obsoleting RFC 2309

On Jul 3, 2014, at 10:22 AM, John Leslie <[email-masked]> wrote:

> It would be possible for someone to argue that restating a 
> recommendation from another document weakens both statements; but I 
> disagree: We should clearly state what we mean in this document, and I 
> believe this wording does so.

The argument for putting it in there started from the fact that we are obsoleting 2309, as stated in the charter. I would understand a document that updates 2309 to be in a strange state if 2309 is itself made historic or obsolete. So we carried the recommendation into this document so it wouldn't get lost.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 14 Jul 2014 18:23:23 +0000

> Given that (W)RED has been deployed extensively in operators' networks, and most vendors are still shipping equipment with (W)RED, concern is that obsoleting 2309 would discourage research on tryin…

Well, note that we’re not saying to pull RED out of the network; we’re saying to not make it the default. Note that even in the networks you mention, (W)RED is not the default configuration; you have to give it several parameters, and therefore have to actively turn it on.

> Prefer John's proposal of updating 2309 rather than obsoleting, but if we can have some text in Fred's draft acknowledging the large deployment of (W)RED and the need to still find good configurati…

The existing draft doesn’t mention any specific AQM algorithms. It seems to me that the more consistent approach would be to write a short draft documenting WRED, that the WG could pass along as informational or experimental on the basis of not meeting the requirements of being self-configuring/tuning, at the same time as it passes along others as PS or whatever.

---

From: Dave Taht <[email-masked]>
Date: Mon, 14 Jul 2014 12:00:02 -0700

> We had previously given a presentation at the ICCRG on why RED can still provide value to operators (http://www.ietf.org/proceedings/88/slides/slides-88-iccrg-0.pdf). We have a paper at Globecom 20…

My problem with with the above preso and no doubt the resulting study
is that it doesn't appear cover the classic, most basic, bufferbloat
scenario, which is

"1 stream up, 1 stream down, one ping (or some form of voip-like
traffic)" and usually on an edge network with asymmetric bandwidth.

It's not clear from the study that this is a 8mbit down 1mbit up DSL
network (?), nor is it clear if RED is being applied in both
directions or only one direction onl?  (and the results you get from
an asymmetric network are quite interesting, particularly in the face
of any cross traffic at all)

And I do keep hoping that someone will do a study of how prevalent fq
is on dsl devices, I keep accumulating anecdotal data that it's fairly
common.

> In it we show that the previous studies which showed low value for RED used web traffic which had very small file sizes (of the order of 5-10 packets), which reduces the effectives of all AQMs whic…

I tend to disagree with this, (well, not the trendline to big video
flows) but my own studies are focused on retaining high performance
gaming, voip, and videoconferencing traffic in the face of things like
HAS video traffic. I would be much happier about your study had you
also run that sort of traffic while testing your video downloads and
aqms... and why is it so hard to get folk to try sfq_codel, etc, while
they try everything else?

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

---

From: Dave Taht <[email-masked]>
Date: Mon, 14 Jul 2014 12:01:27 -0700

> The existing draft doesn’t mention any specific AQM algorithms. It seems to me that the more consistent approach would be to write a short draft documenting WRED, that the WG could pass along as in…

I strongly support a good, consistent set of recommendations for how,
when, and where to use and not use WRED.

-- 
Dave Täht

---

From: "Akhtar, Shahid (Shahid)" <[email-masked]>
Date: Tue, 15 Jul 2014 17:45:59 +0000

Fred,

Per you last text below, are you asking for a short informational draft where we describe our experiments and summarize our configuration guidelines specifically for RED in access downlinks. Is this what you mean by "documenting WRED"?

-Shahid.

-----Original Message-----
From: aqm [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
Sent: Monday, July 14, 2014 1:23 PM
To: Akhtar, Shahid (Shahid)
Cc: John Leslie; [email-masked]
Subject: Re: [aqm] Obsoleting RFC 2309

> Given that (W)RED has been deployed extensively in operators' networks, and most vendors are still shipping equipment with (W)RED, concern is that obsoleting 2309 would discourage research on tryin…

Well, note that we're not saying to pull RED out of the network; we're saying to not make it the default. Note that even in the networks you mention, (W)RED is not the default configuration; you have to give it several parameters, and therefore have to actively turn it on.

> Prefer John's proposal of updating 2309 rather than obsoleting, but if we can have some text in Fred's draft acknowledging the large deployment of (W)RED and the need to still find good configurati…

The existing draft doesn't mention any specific AQM algorithms. It seems to me that the more consistent approach would be to write a short draft documenting WRED, that the WG could pass along as informational or experimental on the basis of not meeting the requirements of being self-configuring/tuning, at the same time as it passes along others as PS or whatever.

>> disagree: We should clearly state what we mean in this document, and 
>> I believe this wording does so.
>

---

From: "Akhtar, Shahid (Shahid)" <[email-masked]>
Date: Tue, 15 Jul 2014 17:46:04 +0000

Dave,

The message of the results that we presented in November is that it is possible, with currently deployed access hardware, to configure RED so that it consistently improves the end user experience of common network services over Tail-Drop (which is most often configured), and that this improvement can be achieved with a fixed set of RED configuration guidelines. 

We did not run experiments with sfq_codel because it is not deployed in access networks today. We ran experiments with plain CoDel to understand the difference between a well-configured RED and a more recent single-bucket AQM in our target scenarios, and as reported, didn't observe significant differences in application QoE.

Additional inline clarifications below.

-Shahid.

-----Original Message-----
From: Dave Taht [mailto:[email-masked]] 
Sent: Monday, July 14, 2014 2:00 PM
To: Akhtar, Shahid (Shahid)
Cc: Fred Baker (fred); John Leslie; [email-masked]
Subject: Re: [aqm] Obsoleting RFC 2309

> We had previously given a presentation at the ICCRG on why RED can still provide value to operators (http://www.ietf.org/proceedings/88/slides/slides-88-iccrg-0.pdf). We have a paper at Globecom 20…

My problem with the above preso and no doubt the resulting study is that it doesn't appear cover the classic, most basic, bufferbloat scenario, which is

"1 stream up, 1 stream down, one ping (or some form of voip-like traffic)" and usually on an edge network with asymmetric bandwidth.

SA: We tried to cover the typical expected traffic over the Internet. Most of the traffic is now HAS traffic (as per the sandvine report), so if only a single stream is present, it is likely to be HAS. The closest approximation of a continuous TCP stream, as you mention, would be a progressive download which can last long enough to look continuous. These were modeled together with other types of traffic.

It's not clear from the study that this is a 8mbit down 1mbit up DSL network (?), 

SA: In the study presented, It was 8M down and 1.6M up - slide 9

nor is it clear if RED is being applied in both directions or only one direction onl?  

SA: AQMs (including RED) were only applied in downstream direction - slide 9

(and the results you get from an asymmetric network are quite interesting, particularly in the face of any cross traffic at all)

SA: I am not sure what you mean by cross-traffic, the DSL link only goes to one residence (or business). The typical traffic to that was modeled.

And I do keep hoping that someone will do a study of how prevalent fq is on dsl devices, I keep accumulating anecdotal data that it's fairly common.

I tend to disagree with this, (well, not the trendline to big video
flows) but my own studies are focused on retaining high performance gaming, voip, and videoconferencing traffic in the face of things like HAS video traffic. I would be much happier about your study had you also run that sort of traffic while testing your video downloads and aqms... and why is it so hard to get folk to try sfq_codel, etc, while they try everything else?

SA: We did not model smaller flows (in terms of throughput). Small UDP flows, which I assume all/most of the above would fall in, would benefit significantly with RED - slide 13 shows much lower average queue length with RED. Other studies have shown that small UDP flows with lots of TCP traffic benefit significantly with RED achieving lower packet loss (M. Mays et al, “Reasons not to deploy RED”). 

--
Dave Täht