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

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 28 Oct 2014 11:18:15 +0100

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.