> On Thu, Feb 13, 2014 at 4:30 PM, Fred Baker (fred) <[email protected]> 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, <[email protected]> >> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/aqm >> >> >> _______________________________________________ >> aqm mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/aqm >> > > > > -- > Dave Täht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
