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

[Dave Taht]

On Thu, Feb 13, 2014 at 4:30 PM, Fred Baker (fred) <fred at cisco.com> wrote:
> 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 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)

> 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, <internet-drafts at ietf.org>
>  wrote:
>
>>
>> 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/
>>
>> _______________________________________________
>> aqm mailing list
>> aqm at ietf.org
>> https://www.ietf.org/mailman/listinfo/aqm
>
>
> _______________________________________________
> aqm mailing list
> aqm at ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>



-- 
Dave Täht

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