[tcpm] Response to WGLC comments on draft-ietf-tcpm-newcwv-09
gorry@erg.abdn.ac.uk Mon, 13 April 2015 10:22 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834E61B3123 for <tcpm@ietfa.amsl.com>; Mon, 13 Apr 2015 03:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.389
X-Spam-Level: *
X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 NTmAO67dSwLM for <tcpm@ietfa.amsl.com>; Mon, 13 Apr 2015 03:22:25 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 38E461B3122 for <tcpm@ietf.org>; Mon, 13 Apr 2015 03:22:25 -0700 (PDT)
Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id D9EAE1B00139 for <tcpm@ietf.org>; Mon, 13 Apr 2015 11:22:38 +0100 (BST)
Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Mon, 13 Apr 2015 11:21:45 +0100
Message-ID: <4996bc5a8214190d17e32ce06923688a.squirrel@erg.abdn.ac.uk>
Date: Mon, 13 Apr 2015 11:21:45 +0100
From: gorry@erg.abdn.ac.uk
To: tcpm@ietf.org
User-Agent: SquirrelMail/1.4.23 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpm/TIvy6IHL-XaZCXTxKiO5F0p8VtU>
Subject: [tcpm] Response to WGLC comments on draft-ietf-tcpm-newcwv-09
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Apr 2015 10:22:26 -0000
The authors received some comments on rev -09 during WGLC, and propose uploading a new rev to address these issues. Copies of the proposed changes are listed in the email below. Best wishes, Gorry, Raffaello and Arjuna. ---- Section 1.1 Implementation of new CWV * A new section was added to introduce the places where there are implementation flexibility: The method specified in this document is a sender-side only change to the the TCP congestion control behaviour of TCP. The method creates a new protocol state, and requires a sender to determine when the cwnd is validated or non-validated to control the entry and exit from this state XREF=state-rule. It defines how a TCP sender manages the growth of the cwnd using the set of rules defined in XREF=new-cwv-section. Implementation of this specification requires an implementor to define a method to provide a measure for the volume of recently acknowledged data (pipeACK). The details of this measurement are implementation-specific. An example is provided in XREF=examples-pipeACK, but other methods are permitted. A sender also needs to provide a method to determine when it becomes cwnd-limited. Implementation of this may require consideration of other TCP methods (see XREF=examples-cwnd-limited). A sender is also recommended to provide a method that controls the maximum burst size XREF=pacing. However, implementors are allowed flexibility in how this method is implemented and the choice of an appropriate method is expected to depend on the way in which the sender stack implements other TCP methods (such as TCP Segment Offload, TSO). ---- Section 4.4 * Clarified that the MUST is to satisfy the goal to avoid a TCP sender growing a large "non-validated" cwnd, when it has not recently sent using the current size of cwnd: The sender is REQUIRED to detect the cwnd-limited condition using a method that conforms to the rules in this section. Example solutions can be found in Section 4.5. * Fixed format of bullet 2 in 4.4. Section 4.5.2: * Replacement text (improved wording): A sender needs to implement a method that detects the cwnd-limited condition (see <xref>). This detects a condition where a sender in the non-validated phase receives an ACK, but the size of cwnd prevents sending more new data. In simple terms, this condition is true only when the FlightSize of a TCP sender is equal to or larger than the current cwnd. However, an implementation also needs to consider constraints on the way in which the cwnd variable can be used, for instance implementations need to support other TCP methods such as the Nagle Algorithm and TCP Segment Offload (TSO) that also use cwnd to control transmission. These other methods can result in a sender becoming cwnd-limited when the cwnd is nearly, rather than completely, equal to the FlightSize.