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

From: [email-masked]
Date: Thu, 13 Feb 2014 13:20:19 -0800

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-02.txt
	Pages           : 22
	Date            : 2014-02-13

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

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

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: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 13 Feb 2014 21:30:40 +0000

Gorry and I have posted a second update to the AQM Recommendations draft discussed at IETF 88. This update mostly picks up nit-level matters.

We, of course, invite review, and would suggest that reviews look at this version.

A diff from IETF 88's version may be found at

http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-aqm-recommendation-00.txt&url2=http://tools.ietf.org/id/draft-ietf-aqm-recommendation-02.txt

which is also http://tinyurl.com/k9tfufm

On Feb 13, 2014, at 1:20 PM, <[email-masked]>
 wrote:

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

---

From: Dave Taht <[email-masked]>
Date: Thu, 13 Feb 2014 19:33:40 -0500

> We, of course, invite review, and would suggest that reviews look at this version.

A few nits.

A) I have not bought into byte-pkt. I don't want to go into it today.

In particular, I'd like the original pie benchmarks rerun now that
that code doesn't have a byte sensitive dropping mode, and the two
compared.

Perhaps that would shed some light on the issue.

B) "Another topic requiring consideration is the appropriate granularity
   of a "flow" when considering a queue management method.  There are a
   few "natural" answers: 1) a transport (e.g. TCP or UDP) flow (source
   address/port, destination address/port, Differentiated Services Code
   Point - DSCP); 2) a source/destination host pair (IP addresses,
   DSCP); 3) a given source host or a given destination host.

add:

4) 5 tuple consisting of source ip/port, dest/port, proto.

And we can hash it out later.

C) " We
   suggest that the source/destination host pair gives the most
   appropriate granularity in many circumstances. "

Back that up with measurements of real traffic from real homes and
small businesses, and I'll believe you. Breaking up packet trains back
into packets in sane ways is the only way to deal with the impact
of iw10 at low bandwidths that I can think of, in particular.

In the interim I would suggest language that waffles more as to
appropriate methods.

D) "Traffic
   classes may be differentiated based on an Access Control List (ACL),
   the packet DiffServ Code Point (DSCP) [RFC5559], setting of the ECN
   field[RFC3168] [RFC4774] or an equivalent codepoint at a lower layer."

Are you ruling out port number? I have no problem with (for example)
deprioritizing port 873 (rsync) somewhat relevant to other traffic. Same
goes for some other well known ports...

Are you ruling out protocol number?

Destination address? (stuff inside my network gets treated
differently than stuff egressing)

These are all common methods of classifying traffic that has
codepoints that cannot be trusted.

And regrettably, on inbound from another domain, diffserv values
cannot be trusted, period. I don't know how to fit that into this draft, but
a MUST regarding remarking inbound diffserv appropriately is
needed. Right now I just quash everything inbound to BE.

E) "A malfunctioning or non-conforming
   network device may similarly "hide" an ECN mark.  In normal operation
   such cases should be very uncommon."

I disagree with the last sentence. ECN unleashed will be ECN abused.

If the recent ntp flooding attacks were ECN marked, and ECN widely
deployed, what would have happened?

(I still strongly support the notion of ECN, but don't want to
deprecate the dangers)

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: [email-masked]
Date: Fri, 14 Feb 2014 08:02:58 -0000

>> Gorry and I have posted a second update to the AQM Recommendations draft
>> discussed at IETF 88. This update mostly picks up nit-level matters.
>>
I'm not sure I understand the comment, but new data is always good.

> 4) 5 tuple consisting of source ip/port, dest/port, proto.
We could add MF-Classifier - I personally  would have no problems with that.

> In the interim I would suggest language that waffles more as to
Maybe this relates to your position in the Internet - edge device v. other
places. We could say something on this?

> needed. Right now I just quash everything inbound to BE.
Ports and the rest would be covered by MF-Classifier?

I don't think a tutorial of DS fits in  this particular draft, although if
the IETF adopts draft-geib-tsvwg-diffserv-intercon, it would relate to the
topic you mention.

> (I still strongly support the notion of ECN, but don't want to
If I understand, you're suggesting that the group should unpick the last
sentence, and explain more. Speaking only for myself, I'm tempted to agree
- ECN also needs something to keep it sane.

Do you have some suggested text here?

Gorry

> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
>