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