Re: [conex] TPC mods: Sender-side Modifications

Mirja Kühlewind <> Tue, 04 November 2014 19:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 890F51A6FDD for <>; Tue, 4 Nov 2014 11:20:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.494
X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5s7G-s9jhKwe for <>; Tue, 4 Nov 2014 11:20:27 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6DE711A6F1E for <>; Tue, 4 Nov 2014 11:20:27 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8E33D930B; Tue, 4 Nov 2014 20:20:25 +0100 (MET)
X-Virus-Scanned: by amavisd-new on
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id qMaujv0JGo4i; Tue, 4 Nov 2014 20:20:25 +0100 (MET)
Received: from [] ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by (Postfix) with ESMTPSA id 67D6BD930A; Tue, 4 Nov 2014 20:20:25 +0100 (MET)
Message-ID: <>
Date: Tue, 04 Nov 2014 20:20:25 +0100
From: Mirja Kühlewind <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Nandita Dukkipati <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ConEx IETF list <>
Subject: Re: [conex] TPC mods: Sender-side Modifications
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Nov 2014 19:20:32 -0000

How about:

"This section gives an overview of actions that need to be taken by a TCP sender 
that would like to use ConEx signaling."

A reference to the subsequent sections is given in the last paragraph below. Is 
this sufficient for you?


On 03.11.2014 07:59, Nandita Dukkipati wrote:
> Mirja,
> What exactly do you intend the Section 2 to be - is this Section meant to
> be an an Overview of the sender side modifications? If so, can we
> explicitly state so.
> I am asking because the actual details of the sender size modifications are
> described in Section 3 and 4.
> A couple of comments in line.
>> 2.  Sender-side Modifications
>> <Please write 1-2 introductory sentences describing the high level bits
> that a reader should expect in this Section. This will also serve as a
> smooth transition into this Section.>
>>     A ConEx sender MUST negotiate for both SACK and ECN or the more
>>     accurate ECN feedback in the TCP handshake if these TCP extension are
>>     available at the sender.  Thus a ConEx SHOULD also implement SACK and
>>     ECN.
> "Thus a ConEx SHOULD..." -> This a ConEx sender SHOULD...
>> Depending on the capability of the receiver, the following
>>     operation modes exist:
>>     o  SACK-accECN-ConEx (SACK and accurate ECN feedback)
>>     o  accECN-ConEx (no SACK but accurate ECN feedback)
>>     o  ECN-ConEx (no SACK and no accurate ECN feedback but 'classic' ECN)
>>     o  SACK-ECN-ConEx (SACK and 'classic' instead of accurate ECN)
>>     o  SACK-ConEx (SACK but no ECN at all)
>>     o  Basic-ConEx (neither SACK nor ECN)
>>     A ConEx sender MUST expose all congestion information to the network
>>     according to the congestion information received by ECN or based on
>>     loss information provided by the TCP feedback loop.  A TCP sender
>>     SHOULD account congestion byte-wise (and not packet-wise).  A sender
>>     MUST mark subsequent packets (after the congestion notification) with
>>     the respective ConEx bit in the IP header.  Furthermore, a ConEx
>>     sender must send enough credit to cover all experienced congestion
>>     for the connection so far, as well as the risk of congestion for the
>>     current transmission (see Section 4.2.
>>     With SACK only the number of lost payload bytes is known, but not the
>>     number of packets carrying these bytes.  With classic ECN only an
>>     indication is given that a marking occurred but not the exact number
>>     of payload bytes nor packets.  As network congestion is usually byte-
>>     congestion [draft-briscoe-tsvwg-byte-pkt-mark], the exact number of
>>     bytes should be taken into account, if available, to make the ConEx
>>     signal as exact as possible.
>>     Detailed mechanisms for congestion accounting in each operation mode
>>     are described in the next section.  Further handling of the IPv6 bits
>>     itself if congestion was accounted is described in the subsequent
>>     section afterwards.