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

From: [email-masked]
Date: Tue, 01 Jul 2014 02:15:19 -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-06.txt
	Pages           : 27
	Date            : 2014-07-01

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, updated
   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-06

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

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: Gorry Fairhurst <[email-masked]>
Date: Wed, 02 Jul 2014 10:58:14 +0100

To keep things clear, we published a new revision of the AQM 
recommendations (-06) after the conference call for which Richard sent 
notes.

Our hope is that this provides a firm basis for any further discussion. 
The editors are asking the group to read this and note any errors.

There remains some on-going discussion about whether this now should 
move RFC2309 to Historic, or not. This issue needs to be resolved before 
we finalize the introduction. Let's hope we can conclude this soon.

Best wishes,

Gorry

On 01/07/2014 10:15, [email-masked] wrote:
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>

---

From: [email-masked]
Date: Thu, 24 Jul 2014 21:00:13 +0100

I'm forwarding this with Bob's permission, as a response to the edits he
requested in WGLC. I shall incorporate changes in the revision we are now
preparing (-07).

Gorry

>
> At 14:37 23/07/2014, [email-masked] wrote:
>>Thanks for the careful read. These are all OK. I'll add them to rev -07
>>within a week or so.
>>
>>I'd like to take these as proposed resolutions to the WGLC comments. With
>>this in mind, can I copy this email to the list Bob?
>>
>>Gorry
>>
>> > Gorry, Fred,
>> >
>> > Thank you v much for the new intro. You've done a great job.
>> > Now that it's not tied to the structure of 2309, it is much much
>> > easier to understand.
>> >
>> > Below are nitty things I've noticed in the new introductory sections
>> > (up to section 3). Nothing controversial. I haven't cc'd to list, so
>> > you can choose to ignore these (given WG last call has passed), but
>> > you'll probably want to fix them - I've suggested text in each case.
>> >
>> > 1. Intro
>> > s/for a variety traffic of traffic/
>> >   /for a variety of traffic/
>> >
>> > s/ In the current Internet and low latency/
>> >   / In the current Internet low latency/
>> >
>> > Section 1.1
>> >          "congestion signals (i.e., marked or dropped packets) "
>> > The concept of ECN marking has not been introduced yet. How about:
>> >          "congestion signals (i.e., packets that are dropped or
>> > marked with explicit congestion notification [RFC3168])
>> >
>> > Section 2.
>> > s/ The solution to the full-queues problem is for network
>> >     devices to drop packets before a queue becomes full,/
>> >   /The solution to the full-queues problem is for network
>> >     devices to drop or ECN-mark packets before a queue becomes full,/
>> >
>> > s/By dropping packets before buffers overflow,
>> >     AQM allows network devices to control when and how many packets to
>> >     drop./
>> >   /By dropping or ECN-marking packets before buffers overflow,
>> >     AQM allows network devices to control when and how many packets to
>> >     drop./
>> >
>> > Section 2.1
>> > "  AQM
>> >     mechanisms need to control the overall queue sizes, to ensure that
>> >     arriving bursts can be accommodated without dropping packets.  AQM
>> >     should also be used to control the queue size for each individual
>> >     flow or class,
>> > "
>> > s/AQM mechanisms need to control the overall/
>> >   /AQM mechanisms might need to control the overall/
>> >
>> > Rationale:
>> > This implies AQM is needed for the overall queue, and for each
>> > individual class. Is the former actually known to be true? If not, I
>> > don't believe this should be stated with such certainty.
>> >
>>Fred are you OK with this?
>>
>> > Section 3.
>> > "   It is convenient to divide flows into three classes: (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.
>> > "
>> > The names of the 3 categories and their later definitions could be
>> > understood by the reader as points on the spectrum, not the regions
>> > between the points.
>> > The subsequent section headings need to be disambiguated too.
>> >
>> > "congestive collapse [RFC2309]."
>> > You're referring to an RFC that you are obsoleting!
>> >
>> > s/congestion control in the application [RFC5405]./
>> >   /congestion control in the application [RFC5405], [RFC6679].
>> >
>> > s/granugranularity/
>> >   /granularity/
>> >
>> > I'd like to suggest an item 5) for the list of granularities:
>> >   5) a class per site (enterprise or residential).
>> > We never use a granularity lower than this as a carrier, other than
>> > in the home gateway.
>> >
>>I'd also be Ok with this.
>>
>> > But this last one is probably beyond a nit, so you can ignore it at
>> this
>> > stage.
>> >
>> >
>> > That's it. HTH
>> >
>> >
>> >
>> > Bob
>> >
>>Gorry
>>
>> > At 10:58 02/07/2014, Gorry Fairhurst wrote:
>> >>Our hope is that this provides a firm basis for any further
>> >>discussion. The editors are asking the group to read this and note any
>> >> errors.
>> >>
>> >>move RFC2309 to Historic, or not. This issue needs to be resolved
>> >>before we finalize the introduction. Let's hope we can conclude this
>> >> soon.
>> >>
>> >>Best wishes,
>> >>
>> >>Gorry
>> >>
>> >>
>> >>
>> >>>   This draft is a work item of the Active Queue Management and
>> >>> Packet Scheduling Working Group of the IETF.
>> >>>
>> >>>     concerning measures to improve and preserve Internet
>> performance.
>> >>> It
>> > ________________________________________________________________
>> > Bob Briscoe,                                                  BT
>> >
>
> ________________________________________________________________
> Bob Briscoe,                                                  BT
>