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

From: Nandita Dukkipati <[email-masked]>
Date: Sun, 2 Nov 2014 22:59:53 -0800

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

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 04 Nov 2014 20:20:25 +0100

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?

Mirja