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

[[e-mail]]

> On Thu, Feb 13, 2014 at 4:30 PM, Fred Baker (fred) <[e-mail]> 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.
>
I'm not sure I understand the comment, but new data is always good.

> 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.
>
We could add MF-Classifier - I personally  would have no problems with that.

> 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.
>
Maybe this relates to your position in the Internet - edge device v. other
places. We could say something on this?

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

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

>> 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, <[e-mail]>
>>  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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/aqm
>>
>>
>> _______________________________________________
>> aqm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/aqm
>>
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
>
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm
>