[conex] New: draft-briscoe-conex-re-ecn-tcp-00 & re-ecn-motiv-00

[Bob Briscoe <[e-mail]>]

ConEx folks,

You may have noticed two old re-ECN drafts just got posted with the 
tag in their filename changed from tsvwg to conex:
* draft-briscoe-conex-re-ecn-tcp-00.txt
* draft-briscoe-conex-re-ecn-motiv-00.txt

This is just to reassure the list that we're not trying to get these 
drafts adopted. In fact in the header we've put "Intended Status: 
Historic", and we've put a big note in the abstract about historic status.

Reasons for re-posting:
a) to keep them sufficiently alive to be referenced from the 
conex-abstract-mech draft
b) to be able to point to them from BT's patent declaration
c) to bring them under the conex heading, not tsvwg
d) to allow for the possibility of getting them turned into historic 
RFCs if the ConEx WG want that.
e) identify errors and gaps so they can be carried over to ConEx work 
where relevant
f) much of the re-ecn-motive draft is just as applicable to ConEx 
(mostly about audit and policing), so pls feel free to lift text into 
ConEx drafts if you want.

We've revealed items tagged 'ToDo', that were previously only 
comments within the XML source. This will help people see that these 
drafts are incomplete, and it records potential open issues for the 
ConEx w-g to take on board.

I did spend a couple of hours clarifying some aspects of these drafts 
that could otherwise cause unfamiliar readers to get confused about 
how they relate to current ConEx work.

Full diffs from previous version:
<http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp-09.txt&url2=http://tools.ietf.org/id/draft-briscoe-conex-re-ecn-tcp-00.txt>



Bob


>From: <[e-mail]>
>To: <[e-mail]>
>CC: <[e-mail]>, <[e-mail]>, <[e-mail]>
>Subject: New Version Notification for draft-briscoe-conex-re-ecn-tcp-00.txt
>
>A new version of I-D, draft-briscoe-conex-re-ecn-tcp-00.txt has been 
>successfully submitted by Bob Briscoe and posted to the IETF repository.
>
>Filename:       draft-briscoe-conex-re-ecn-tcp
>Revision:       00
>Title:          Re-ECN: Adding Accountability for Causing Congestion to TCP/IP
>Creation date:  2012-04-22
>WG ID:          Individual Submission
>Number of pages: 52
>
>Abstract:
>    This document introduces re-ECN (re-inserted explicit congestion
>    notification), which is intended to make a simple but far-reaching
>    change to the Internet architecture.  The sender uses the IP header
>    to reveal the congestion that it expects on the end-to-end path.  The
>    protocol works by arranging an extended ECN field in each packet so
>    that, as it crosses any interface in an internetwork, it will carry a
>    truthful prediction of congestion on the remainder of its path.  It
>    can be deployed incrementally around unmodified routers.  The purpose
>    of this document is to specify the re-ECN protocol at the IP layer
>    and to give guidelines on any consequent changes required to
>    transport protocols.  It includes the changes required to TCP both as
>    an example and as a specification.  It briefly gives examples of
>    mechanisms that can use the protocol to ensure data sources respond
>    sufficiently to congestion, but these are described more fully in a
>    companion document.
>
>    Note concerning Intended Status: If this draft were ever published as
>    an RFC it would probably have historic status.  There is limited
>    space in the IP header, so re-ECN had to compromise by requiring the
>    receiver to be ECN-enabled otherwise the sender could not use re-ECN.
>    Re-ECN was a precursor to chartering of the IETF&#39;s Congestion
>    Exposure (ConEx) working group, but during chartering there were
>    still too few ECN receivers enabled, therefore it was decided to
>    pursue other compromises in order to fit a similar capability into
>    the IP header.
>
> 
>
>
>
>The IETF Secretariat

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design