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

Nandita Dukkipati <nanditad@google.com> Mon, 03 November 2014 06:59 UTC

Return-Path: <nanditad@google.com>
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 2DF711A1A5E for <conex@ietfa.amsl.com>; Sun, 2 Nov 2014 22:59:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.028
X-Spam-Level: *
X-Spam-Status: No, score=1.028 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] 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 RZHmq7vj_INf for <conex@ietfa.amsl.com>; Sun, 2 Nov 2014 22:59:54 -0800 (PST)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94111A1A5D for <conex@ietf.org>; Sun, 2 Nov 2014 22:59:54 -0800 (PST)
Received: by mail-oi0-f52.google.com with SMTP id u20so8121264oif.25 for <conex@ietf.org>; Sun, 02 Nov 2014 22:59:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6Ea8CAni8IdMAAS9BD7KDNWFmt45DApHxD/7LZvPnE0=; b=TQuyZxnu4nL72zxKnAAe8dXOz0hdPr5wXilU6I8+B+BY03waXpjqHvI+ctGcOMi6y9 PoMR9c7ZdGI/nkVC0qiS3xEArgejQwYAITKURIKRNJbFxKmnepvqtOahqPloJw8EAWY3 VPumxzFuIDTTkFHIznWCWLQ1nd00nR2EqmCpmHaS+bNHmewrt9af3lNTE1idWg9pMQ0o NCiF9D3wZ6fVyYEmX3MNBKXuLNIAm7aBn+wPNzr1vnBxb41r5TnrEeqgHKutPHIKWRZh 8rV4kbPIKTyY41BzObDJuli5IWMKBfSbUsWGFO4d93vhaRJRppDAFgygUCM77/MnbY+a Z+yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6Ea8CAni8IdMAAS9BD7KDNWFmt45DApHxD/7LZvPnE0=; b=QQhNxBeOwepo8fcxX9RVSOhZHGv7NHcliSaAcU5q41EGMn1YXnzURcGKb+SfRYtc+H 6oHPw6hEMf2dPl3e1FyR6V0NvQUM8Y9ynEArPOnK96s/kB5imA7g5RlNqAVSoFmuTN43 yQiHxjLOsDhvJTb5OT7jw96aO98QCY+iT7IhyOVCanQPhM3CWJqr5dE2aMP/KWD6xVT7 oKNXQqi+zY8e9ULgu5JrUkO9pwaDFWYPbKmY2kPz+GQEpgzJ/sAGa47ohASJnui3t/Mo wxcJ8V3D8EVzanGRG1At+syb71RbSMOX8AH0JN4ZYGHHGdu61zXSr/hUrlJCVTZP2J5p 495g==
X-Gm-Message-State: ALoCoQkyOmMZLYLXnJb//1XWryfKJvLdZOWqWYIvzIre+3Jpjcg94NNQiwewqgQwd3BONosKToDB
MIME-Version: 1.0
X-Received: by 10.182.215.136 with SMTP id oi8mr35634789obc.18.1414997994051; Sun, 02 Nov 2014 22:59:54 -0800 (PST)
Received: by 10.182.248.161 with HTTP; Sun, 2 Nov 2014 22:59:53 -0800 (PST)
In-Reply-To: <544F6D67.1040606@tik.ee.ethz.ch>
References: <544F6D67.1040606@tik.ee.ethz.ch>
Date: Sun, 02 Nov 2014 22:59:53 -0800
Message-ID: <CAB_+Fg7wea4UEJMfL8yP73C5k1in1n4WPzuqve7Ye10W7a8UdA@mail.gmail.com>
From: Nandita Dukkipati <nanditad@google.com>
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Content-Type: multipart/alternative; boundary="001a11c24f28cb3cb30506eee403"
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/WBZj3SMfuqxgKUzgi2S47W2vews
Cc: ConEx IETF list <conex@ietf.org>
Subject: Re: [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: Mon, 03 Nov 2014 06:59:59 -0000

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