[aqm] Spencer Dawkins' Yes on draft-ietf-aqm-recommendation-09: (with COMMENT)
"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> Mon, 16 February 2015 20:41 UTC
Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B021A88B4; Mon, 16 Feb 2015 12:41:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSfQOAZc6Fxp; Mon, 16 Feb 2015 12:41:43 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D69071A88AF; Mon, 16 Feb 2015 12:41:43 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.11.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150216204143.14904.65612.idtracker@ietfa.amsl.com>
Date: Mon, 16 Feb 2015 12:41:43 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/de9_PuN880kcjQ9KRT5-EmzXIRk>
Cc: rs@netapp.com, aqm-chairs@ietf.org, aqm@ietf.org, draft-ietf-aqm-recommendation.all@ietf.org
Subject: [aqm] Spencer Dawkins' Yes on draft-ietf-aqm-recommendation-09: (with COMMENT)
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Feb 2015 20:41:46 -0000
Spencer Dawkins has entered the following ballot position for draft-ietf-aqm-recommendation-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I appreciate very much the work on this document. I'm a Yes, with some niggling. In this text: Abstract The note largely repeats the recommendations of RFC 2309, and replaces these after fifteen years of experience and new research. I'm thinking that doesn't match the "replaces" language in section 1.4, which I think is about right. Perhaps something like The note replaces the recommendations of RFC 2309 based on fifteen years of experience and new research. In this text: 1.1. Congestion Collapse The original fix for Internet meltdown was provided by Van Jacobsen. Beginning in 1986, Jacobsen developed the congestion avoidance mechanisms [Jacobson88] that are now required for implementations of the Transport Control Protocol (TCP) [RFC0768] [RFC1122]. I'm wondering if RFC 7414 would be a helpful reference here, and elsewhere in the document. I'm bemused by the use of RFC 793 as the reference for TCP later in this document, since RFC 793 TCP behaves nothing like TCP as characterized here. I know I'm confused by the reference to RFC 768 - that's UDP, as cited correctly elsewhere in the document. In this text: 2. Non-Responsive Flows The User Datagram Protocol (UDP) [RFC0768] provides a minimal, best-effort transport to applications and upper-layer protocols (both simply called "applications" in the remainder of this document) and does not itself provide mechanisms to prevent congestion collapse and establish a degree of fairness [RFC5405]. I'm not entirely comfortable with the idea that non-responsive flows use UDP transport (especially in our tunneled world). If you guys think this is OK, I'll hold my nose, but if you wanted to say anything about "other flows that are as non-responsive as UDP transport", I'd think that would be helpful. It certainly fits at least as well as the "large number of short-lived TCP flows that are much less responsive" paragraph that you end this section with, which probably fits better under the following list item, 3. Transport Flows that are less responsive than TCP In this text: It is essential that all Internet hosts respond to loss [RFC5681], [RFC5405][RFC4960][RFC4340]. Packet dropping by network devices that are under load has two effects: It protects the network, which is the primary reason that network devices drop packets. The detection of loss also provides a signal to a reliable transport (e.g. TCP, SCTP) that there is potential congestion using a pragmatic heuristic; "when the network discards a message in flight, it may imply the presence of faulty equipment or media in a path, and it may imply the presence of congestion. To be conservative, a transport must assume it may be the latter." Unreliable transports (e.g. using UDP) need to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ similarly react to loss [RFC5405] ^^^^^^^^^^^^^^^^^^^^^^^ would it be more correct to say "Applications using unreliable transports (e.g. UDP)"?
- [aqm] Spencer Dawkins' Yes on draft-ietf-aqm-reco… Spencer Dawkins