[conex] TCP mods: Intro

[Mirja Kühlewind <[e-mail]>]

Hi Nandita, hi all,

find below the current version of the intro. Sorry for the delay; this 
week was a little busy...

I applied the following changes:

- Paragraph on CDO move back to intro (from section 4)

- Added paragraph explaining that no receiver side changes are needed

- Now introducing loss first

- Added some sentences and the last paragraph to further explain the 
structure of the doc


Mirja

-------------------------------------------------------------
1.  Introduction

    Congestion Exposure (ConEx) is a mechanism by which senders inform
    the network about the congestion encountered by previous packets on
    the same flow.  ConEx concepts and use cases are further explained in
    [RFC6789].  The abstract ConEx mechanism is explained in
    [draft-ietf-conex-abstract-mech].  This document describes the
    necessary modifications to use ConEx with the Transmission Control
    Protocol (TCP).

    ConEx is defined as a destination option for IPv6
    [draft-ietf-conex-destopt].  The use of four bits have been defined,
    namely the X (ConEx-capable), the L (loss experienced), the E (ECN
    experienced) and C (credit) bit.

    Therefore the ConEx signal is based on loss or Explicit Congestion
    Notification (ECN) marks [RFC3168] as a congestion indication.  This
    congestion information is retrieved by the sender based on existing
    feedback mechanisms from the receiver to the sender in TCP.  No
    changes are needed at the receiver to implement ConEx signaling.
    Therefore no additional negotiation is needed to implement and use
    ConEx at the sender.  This document specifies actions needed by
    sender to provide meaningful ConEx information to the network in
    section Section 2.

    Further this document describes congestion accounting for both TCP
    with and without the Selective Acknowledgment (SACK) extension
    [RFC2018] in section Section 3.1.  However, ConEx benefits from more
    accurate information about the number of packets dropped in the
    network.  We therefore recommend using the SACK extension when using
    TCP with ConEx.  The detailed mechanism to respectively set the L bit
    in response to loss-based congestion feedback signal is given in
    section Section 4.1.

    While loss-based congestion feedback should be minimized, ECN could
    actually provide more fine-grained feedback information.  ConEx-based
    traffic measurement or management mechanisms would benefit from this.
    Unfortunately, the current ECN feedback mechanism does not reflect
    multiple congestion markings which occur within the same Round-Trip
    Time (RTT).  A more accurate feedback extension to ECN is defined in
    a separate document [draft-kuehlewind-tcpm-accurate-ecn], as this is
    also useful for other mechanisms.

    The congestion accounting for both, with the classic ECN feedback as
    well as a more accurate ECN feedback are explained in detail in
    section Section 3.2 while the setting of the E bit in response to
    ECN-based congestion feedback is again detailed in section
    Section 4.1.