Subject: [aqm] I-D Action: draft-ietf-aqm-recommendation-07.txt

From: [email-masked]
Date: Tue, 05 Aug 2014 03:18:38 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Active Queue Management and Packet Scheduling Working Group of the IETF.

        Title           : IETF Recommendations Regarding Active Queue Management
        Authors         : Fred Baker
                          Godred Fairhurst
	Filename        : draft-ietf-aqm-recommendation-07.txt
	Pages           : 28
	Date            : 2014-08-05

Abstract:
   This memo presents recommendations to the Internet community
   concerning measures to improve and preserve Internet performance.  It
   presents a strong recommendation for testing, standardization, and
   widespread deployment of active queue management (AQM) in network
   devices, to improve the performance of today's Internet.  It also
   urges a concerted effort of research, measurement, and ultimate
   deployment of AQM mechanisms to protect the Internet from flows that
   are not sufficiently responsive to congestion notification.

   The note largely repeats the recommendations of RFC 2309, and
   replaces these after fifteen years of experience and new research.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-aqm-recommendation-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-recommendation-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: [email-masked]
Date: Tue, 5 Aug 2014 11:23:54 +0100

I've posted a new revision of the draft. This contains a reworked
introduction by Fred & I, which seeks to clarify the intended status of
RFC 2309, and addresses all issues that we planned to address.  We think
this is ready to proceed.

Gorry

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

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 8 Aug 2014 13:24:43 +0000

John, Bob,

had you the chance to review this new revision, which should address the comments you had?

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: aqm [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Dienstag, 05. August 2014 12:24
> To: [email-masked]
> Subject: Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-07.txt
> 
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
> > tools.ietf.org.
> >

---

From: John Leslie <[email-masked]>
Date: Fri, 8 Aug 2014 10:58:35 -0400

> had you the chance to review this new revision, which should address the comments you had?

   I expect to defer to Bob on this; but I read quite a few subtle changes
to 2309 in the restatement here, none of which I believe represent true
consensus of this WG (because they're not our intended subject).

   This is what I was trying to avoid by my suggestion of text to "update"
instead of "obsolete" 2309.

   There's no real show-stopper here -- folks undoubtedly will ignore
these for the most part.

   Nonetheless, it still bothers me to have no definition for terms like
"network device" and "congestive collapse". I tried to roughly define
"network device" in my suggested text; and avoided "congestion collapse"
(the term used in 2309) entirely.

--
John Leslie <[email-masked]>

---

From: [email-masked]
Date: Fri, 8 Aug 2014 17:04:31 +0100

>    I expect to defer to Bob on this;
>
>but I read quite a few subtle changes
If you see ambiguity in "network device", by all means send us propose
text again (I must have missed that detail.

Apart from that, does this mean you have no specific comments on this
version?

Gorry

---

From: John Leslie <[email-masked]>
Date: Sat, 9 Aug 2014 07:27:48 -0400

> text again (I must have missed that detail.

   You're welcome to my text from July 2:

http://www.ietf.org/mail-archive/web/aqm/current/msg00701.html

   I don't know whether that matches your intent: I have no desire to
change your intent.

> Apart from that, does this mean you have no specific comments on this

   If Bob makes any fuss about "congestive collapse" I support him.
Otherwise, I make a strong request that you add a definition of that
term: I have no idea what you mean that's consistent with what you
wrote and the way the Internet works.

   I do remain convinced that the charter wording calling for
obsoleting RFC 2309 was ill-advised, and is not what this WG actually
chose to do. I'd much prefer to fix the charter milestone language;
but I detect no enthusiasm for that. I'll settle for being listed
"in the rough" in the Shepherd's writeup.

   My thorough review was of version -05. Since then, I note the
change in the Abstract from "updated" to "and replaces these"
[recommendations of 2309]. I don't see any particular reason for
that change, but won't fuss over it if nobody else cares.

   I note the addition of a section header for "1.1 Congestion
Collapse" which correctly includes "fix for Internet meltdown"; but
I think the switching between "Congestion Collapse" and "congestive
collapse" is confusing. ("Congestion Collapse" is a well-defined
term of art; and wouldn't need a definiton unless you think you
can write one which will make the usage of that term correct in
this document.)

   Most of my comments about version -05 can simply be listed as
"ignored" or perhaps "considered and ignored"; but a few never made
it onto the list because I thought the change from "obsoletes" to
"updates" needed to be discussed first.

   In Section 3 subsection 3, I would prefer that we not perpetuate
the idea that flows must be "TCP-friendly". While there are indeed
cases of unfriendly-to-TCP flows, that really isn't an AQM issue.

   In Section 4.6, in talking of "elastic transport congestion
control", I fail to see how this relates to AQM; and I'd prefer
not jawboning about how transports "should" function. (This sort
of text would be entirely proper in an IRTF document; but we're
now doing an IETF BCP concerned with queue management in network
devices.)

   Section 4.7 returns to 2309's "need further research" conclusion.
It seems to me out-of-place to list these things in a BCP.

   In Section 8 Acknowledgements, I don't think it correct to say,
"This is an edited version of that document". (I agree it started
that way, but I find that not an acceptable basis for a BCP.)

====

   You have every right to say I should have raised these points
earlier; but that's a poor substitute for evaluating their merit.
It is the intent of a Working Group Last Call to solicit thorough
reviews by WG participants -- and follow through on those with
merit.

   The habit of tossing the WGLC comments at the authors and
marginalizing any further comments to the authors' response is
a bad habit. I wish we would break it.

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 11 Aug 2014 10:09:30 +0100

RIchard,

All my points have been addressed, except one (below). Thank you, Fred & Gorry.

The one about the 3 types of flows has missed my point in a couple of 
ways, (A) & (B) explained below.

Section 3 divides flows into 3 types:
(1) TCP Friendly flows,
(2) unresponsive flows, i.e., flows that do not slow down when 
congestion occurs, and
(3) flows that are responsive but are not TCP-friendly.

A) It might seem obvious to some that "not friendly", means "less 
than friendly", but given the definition of TCP-friendly, "not 
TCP-friendly" is ambiguous and could also mean "more friendly than 
TCP" (e.g. scavenger transports).

Therefore, I suggest changing "not TCP-friendly" and 
"Non-TCP-friendly"  to "less responsive than TCP-Friendly" or some 
similar phrase.

B) My main point was that (1) and (2) are points on a spectrum, and 3 
is a region that spans the whole of the spectrum between these 
points. Then the rest of the doc talks about all three as if they are 
in the same set of types.

That's not a useful classification. Previous docs in the RFC series 
have been careful not to overclaim the importance of precise 
TCP-friendliness. It's not helpful to suggest that anything to the 
left of TCP-Friendly "clearly poses a threat to future Internet 
stability". It would be more useful to describe it as a spectrum with 
two reference points on it (as shown). Then say the closer to the 
unresponsive end that a flow is, the more it could pose a threat to 
the performance of other flows during times of excessive contention.

           Unresponsive                     TCP-Friendly
           |                                     |
           v                                     v
5 5 5 5 5 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 1 4 4 4 4 4 4 4 4 4 4 
4 4 4 4 4 4 4 4
<-Beyond-> <---responsive but less than TCP----> <--responsive but 
more than TCP--->
Unrespons-
   ive

In fact, there is (fairly common) behaviour to the left of 
unresponsive, where a flow adds redundancy. By turning the 
classification into a spectrum, it would be fairly natural to include 
that as well.

Other than this, I don't want to tamper with the text on whether AQMs 
have a role in flow isolation, because it does well to leave the question open.

C) Also (a new point I didn't mention before), the alarmist language 
in two places is rather over-the-top:
* "The last two classes contain more aggressive flows that pose 
significant threats to Internet performance"
* "The projected increase in the fraction of total Internet traffic 
for more aggressive flows in classes 2 and 3 clearly poses a threat 
to future Internet stability"

Suggested text, respectively:
* "The last two classes contain more aggressive flows that can pose 
significant threats to Internet performance"
* "The projected increase in the fraction of total Internet traffic 
for more aggressive flows in classes 2 and 3 could pose a threat to 
future Internet performance"

Note, I've also suggested changing 'stability' to 'performance' - 
this doc has nothing to do with oscillations, etc.

For instance, does VoIP pose a significant threat to Internet 
performance? Nah. Still in some places maybe, but the Internet is 
generally coping. When the Internet was growing up we thought VoIP 
might cause collapse, but our concerns have waned as link capacities 
have grown. So the perception of threat depends on the bit-rate of 
the flow relative to average link capacities.

Responsiveness is important, but I believe it is OK for unresponsive 
flows that are small in relative terms to only be responsive at very 
long timescales (even solely at flow set up - self-admission 
control). This even applies to aggregates of unresponsive flows, 
because they will tend to be deployed where even the aggregate is 
small relative to the link capacity. See 
http://tools.ietf.org/html/draft-ietf-pwe3-congcons-02.pdf (comments 
to the PWE3 list pls).

Bob

> > > ftp://ftp.ietf.org/internet-drafts/

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: [email-masked]
Date: Mon, 11 Aug 2014 14:45:58 +0100

Bob, I see several issues that can easily be resolved by a very minor
revision to take care of this, and my suggested plan is below:

...

> The one about the 3 types of flows has missed my point in a
> couple of  ways, (A) & (B) explained below.

> (2) unresponsive flows, i.e., flows that do not slow
> down when congestion occurs, and

> TCP-friendly" is ambiguous and could also mean "more friendly
> than TCP" (e.g. scavenger transports).

>”Non-TCP-friendly"  to "less responsive than TCP-Friendly" or some
>similar phrase.
>

+GF: Perfect, I like this a lot, and can use "less responsive than TCP" as
a basis for making this better.

> B) My main point was that (1) and (2) are points on a spectrum, and
> 3 is a region that spans the whole of the spectrum between these
> points. Then the rest of the doc talks about all three as if they
> are in the same set of types.
>
+GF: If we change the language above, we can explicitly say this, and I’ll
add text.

————>

> stability". It would be more useful to describe it as a spectrum
> with two reference points on it (as shown).

> Then say the closer to the
4 4 4 4 4 4 4 4

> classification into a spectrum, it would be fairly natural
> to include that as well.
>
+GF: I think the new test should be closer, and I added this to the
"unresponsive" case to explicitly call this out:

Some applications can even increase their traffic volume in response to
congestion (e.g. by adding forward error correction when loss is
experienced), with the possibility that they contribute to congestion
collapse.

> have a role in flow isolation, because it does well to leave the
+GF: That was intended, good.

> C) Also (a new point I didn't mention before), the alarmist
> language in two places is rather over-the-top:
> * "The last two classes contain more aggressive flows
> that can pose  significant threats to Internet performance"
> * "The projected increase in the fraction of total Internet
> traffic for more aggressive flows in classes 2 and 3 could
> pose a threat to

> this doc has nothing to do with oscillations, etc.

+GF: Agree, this text was directly taken from RFC 2309… let's change it
... but how about “dependable performance”? (i'd like to capture that this
isn't performance tuning - but more expectation of performance.

> For instance, does VoIP pose a significant threat to
> Internet  performance? Nah. Still in some places maybe,
> but the Internet is generally coping. When the Internet was
> growing up we thought VoIP might cause collapse, but our
> concerns have waned as link capacities have grown. So the
> perception of threat depends on the bit-rate of

——

> small relative to the link capacity.
> See http://tools.ietf.org/html/draft-ietf-pwe3-congcons-02.pdf
> (comments to the PWE3 list pls).

+GF: I don’t see this needed in this draft.

> Bob

——

+GF: I’m also considering replacing /congestive collapse/ by /congestion
collapse/ which seems a more common term, as noted by John L.

+GF: And I'll rewrite the Acknowledgement text relating to RFC 2309, as
noted by John L.

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 11 Aug 2014 10:08:40 -0400

> +GF: I don’t see this needed in this draft.

I agree; this BCP is about AQM behavior, and not the right place to
hide recommendations or requirements on flow sources.

> collapse/ which seems a more common term, as noted by John L.

I agree with this too.

-- 
Wes Eddy
MTI Systems

---

From: [email-masked]
Date: Mon, 11 Aug 2014 15:56:02 +0100

John,

Thanks for getting back, this is helpful and I can prepare a new revision
to cover the feedback from you and Bob, see below:

GF: I looked, and didn't find a specific definition. The text in the
present draft says (there since -00), which I think is at least a
clarification of what was intended:
"These mechanisms may be implemented in network devices that include
   routers, switches, and other network middleboxes."

GF: The present document uses both "congestion collapse" and "congestive
collapse". I am OK with you proposal:
s/congestive/congestion/g: 4 instances
---
   I do remain convinced that the charter wording calling for
obsoleting RFC 2309 was ill-advised, and is not what this WG actually
chose to do. I'd much prefer to fix the charter milestone language;
but I detect no enthusiasm for that. I'll settle for being listed
"in the rough" in the Shepherd's writeup.

GF: This is what I hear was the result of the consensus call by the Chairs
when the proposed future status for RFC 2309 was agreed.
---
   I note the addition of a section header for "1.1 Congestion
Collapse" which correctly includes "fix for Internet meltdown"; but
I think the switching between "Congestion Collapse" and "congestive
collapse" is confusing. ("Congestion Collapse" is a well-defined
term of art; and wouldn't need a definiton unless you think you
can write one which will make the usage of that term correct in
this document.)

GF: See above change.
---

GF: No No that was not the case - The new text was at least "considered"
in some detail, we went through both the text from Wes, your text and
others line by line before formulating the new revision.
----
   In Section 3 subsection 3, I would prefer that we not perpetuate
the idea that flows must be "TCP-friendly". While there are indeed
cases of unfriendly-to-TCP flows, that really isn't an AQM issue.

GF: I think scheduling and isolation have been discussed within the group,
so I personally don't agree with your view that this is out of scope.
Although I’m no fan of Non-TCP friendly, and would like to replace this
with less responsive that TCP.
---
   In Section 4.6, in talking of "elastic transport congestion
control", I fail to see how this relates to AQM; and I'd prefer
not jawboning about how transports "should" function. (This sort
of text would be entirely proper in an IRTF document; but we're
now doing an IETF BCP concerned with queue management in network
devices.)

GF: I’m thinking CC reacts to AQM to reduce the rate.
---
   Section 4.7 returns to 2309's "need further research" conclusion.
It seems to me out-of-place to list these things in a BCP.

GF: Others have not said this.

---

GF: Indeed, I think we should change this now the document is nearly
ready.  I propose something more like:

NEW:
The original version of this document describing best current practice was
based on the informational text of [RFC2309]. This was written by the
End-to-End Research Group, which is to say Bob Braden, Dave Clark, Jon
Crowcroft, Bruce Davie, Steve Deering, Deborah Estrin, Sally Floyd, Van
Jacobson, Greg Minshall, Craig Partridge, Larry Peterson, KK Ramakrishnan,
Scott Shenker, John Wroclawski, and Lixia Zhang.  Although there are
important differences, many of the key arguments in the present document
remain unchanged from those in RFC 2309.

====

GF: This is more of comment about the IETF contributions, we also in
general benefit when there are more WG contributions to calls for inputs,
instead of leaving review to during or following of WGLC. However, I
personally  think all inputs are valuable, if they present ideas for
improving a document!

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 11 Aug 2014 21:45:51 +0100

Gorry,

>isn't performance tuning - but more expectation of performance.

Dependable performance isn't right. I'd leave it 
as just "...threat to ... performance".

Any protocol or algo that gives you k/N share of 
available capacity doesn't give you dependendable 
performance, because N isn't under your control, only k.

>+GF: I don’t see this needed in this draft.

Sorry, I was just reinforcing my point that "the 
sky is falling" language isn't necessary. I 
didn't intend to say there should be anything 
about any of the specifics in this para in the AQM draft.

>collapse/ which seems a more common term, as noted by John L.

Works for me.

Regards

Bob

---

From: [email-masked]
Date: Tue, 12 Aug 2014 08:35:07 +0100

Bob - those changes are aded.

> performance, because N isn't under your control, only k.
I wasn't thinking that way - so I won't write that, I was wondering how to
write the opposite of lockout. Because performance is one aspect - but
methods to reduce synch and lockout are important also.