From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7DFE821F1BB for ; Thu, 13 Feb 2014 16:33:41 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id c9so18912975qcz.17 for ; Thu, 13 Feb 2014 16:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2o2xREPoKXkO9dAOZ5Zmj/XWOJdHgZLhdKoqvqOWrWU=; b=DaoRoG8NoKENTJhdg6mrWnZOSgfkxz3NPDG15QbpS0hXJxTqy+7r3cD1gjTCSFsvSL SKwKMf42Xe/na6UbYY+NfOhKjLlQ/1A/yYow8xcNdvi9pqFoGGGVSsYKyjHblQhdlB+f HUQ/g9BLN74JCW1DUwabUcCp5OHgttwzcXPHmUTALro16ii3XwdQBvz5cdUytSbtwlvS 4PGHTi+vcK+NyUWXZqBnuz6RK9kNTHm5B2BghQsDWN1vAy2d0OHmqXsrVDSVH2l9ZnOT 9YluJSHEwLgPT5XhRbO3bSRxn584uVFNPTxmpm8KlYYmKsFVrDPpNowVY7lvzCOBtJNG +Fxg== MIME-Version: 1.0 X-Received: by 10.229.193.136 with SMTP id du8mr7885479qcb.11.1392338020281; Thu, 13 Feb 2014 16:33:40 -0800 (PST) Received: by 10.224.27.133 with HTTP; Thu, 13 Feb 2014 16:33:40 -0800 (PST) In-Reply-To: <0B51D150-B5D5-422D-A76C-DD9DFAE7A6F0@cisco.com> References: <20140213212019.12484.97730.idtracker@ietfa.amsl.com> <0B51D150-B5D5-422D-A76C-DD9DFAE7A6F0@cisco.com> Date: Thu, 13 Feb 2014 19:33:40 -0500 Message-ID: From: Dave Taht To: "Fred Baker (fred)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "aqm@ietf.org list" , bloat Subject: Re: [Bloat] [aqm] I-D Action: draft-ietf-aqm-recommendation-02.txt X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 00:33:41 -0000 On Thu, Feb 13, 2014 at 4:30 PM, Fred Baker (fred) 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, bu= t 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=3Dhttp://tools.ietf.org/id/draft-ietf-= aqm-recommendation-00.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-aqm-re= commendation-02.txt > > which is also http://tinyurl.com/k9tfufm > > On Feb 13, 2014, at 1:20 PM, > wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Active Queue Management and Packet Sche= duling Working Group of the IETF. >> >> Title : IETF Recommendations Regarding Active Queue Man= agement >> 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=3Ddraft-ietf-aqm-recommendation-02 >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> 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@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html