[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)"?