[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.