[conex] TPC mods: Sender-side Modifications
Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Tue, 28 October 2014 10:18 UTC
Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02AA1A1AFC for <conex@ietfa.amsl.com>; Tue, 28 Oct 2014 03:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level:
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 XKat0aAAHuHN for <conex@ietfa.amsl.com>; Tue, 28 Oct 2014 03:18:17 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E161A1ADA for <conex@ietf.org>; Tue, 28 Oct 2014 03:18:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2C59FD9305; Tue, 28 Oct 2014 11:18:16 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id i+wrt3gvq5M9; Tue, 28 Oct 2014 11:18:15 +0100 (MET)
Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E810ED9304; Tue, 28 Oct 2014 11:18:15 +0100 (MET)
Message-ID: <544F6D67.1040606@tik.ee.ethz.ch>
Date: Tue, 28 Oct 2014 11:18:15 +0100
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: ConEx IETF list <conex@ietf.org>, Nandita Dukkipati <nanditad@google.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/sYO7I3M4jckOvWehA1r8EPXs6FQ
Subject: [conex] TPC mods: Sender-side Modifications
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex/>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Oct 2014 10:18:21 -0000
Hi Nandita, as we have agreed on the Intro, I am now sending the next section (see below). Mirja ------------------------------------------------------------------------ 2. Sender-side Modifications 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. 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.
- [conex] TPC mods: Sender-side Modifications Mirja Kühlewind
- Re: [conex] TPC mods: Sender-side Modifications Nandita Dukkipati
- Re: [conex] TPC mods: Sender-side Modifications Mirja Kühlewind