[re-ECN] BoF draft charter

[<[e-mail]>]

And a brief email about the charter:

The easiest way to converge to a draft charter is to try and lift text
from one or more of: the BoF proposal Bob submitted; the briefer
proposal I and others came up with; the draft problem statement. We then
need to come up with a realistic list of work items taking into account
Lars's comments regarding the level of detail required.

Here is my initial attempt at something just to get things going.

Congestion Exposure

The Congestion Exposure Working Group develops mechanisms to enable
congestion to be exposed within the network layer of the Internet. The
group will consider mechanisms that require modification of the
end-hosts as well as proxy mechanisms that allow network operators to do
this on behalf of the end-hosts. The initial output of this group is
expected to be informational or experimental.

Other work at the IETF [LEDBAT, ALTO] and IRTF [ICCRG] is looking at new
approaches to controlling bulk data transfer rates. But these new
approaches will only work with the cooperation of the operators. What is
lacking is a mechanism to build trust between operators and end-users
and between different tiers of operators. In short the Internet lacks a
system for accountability.

The congestion exposure protocols developed by this group will enable
operators to monitor traffic according to the actual impact it is having
on other users. This will in turn allow the growth of transports that
seek to reduce their congestion impact.

This Congestion exposure group focuses on exposing the congestion
information that end systems use to determine their transmission. Openly
propagating congestion information can provide the foundations for trust
and accountability throughout the network. Specifically, the protocols
to be considered by this group will expose both the congestion thus far
and the expected rest-of-path congestion in the IP header of each
packet. This ensures that nodes downstream of the source can see the
impact that will be caused by any packet they forward.

Currently a protocol called re-ECN (re-inserted explicit congestion
notification) has been proposed to do this. Re-ECN is the strongest
candidate for adoption, but of course the working group is expected to
redesign and thoroughly test this alongside any alternative if one
surfaces. 

The WG will publish a protocol which enables network operators to count
the volume of congestion for any chosen aggregate of traffic, whether
per customer, per peer, or any other aggregate. The defined protocol
should work with minimal changes to the existing network, in particular
it should work with unmodified routers, but in the long run it is
envisaged these small changes will make a big impact to how the limited
resources of the network are shared.

The working group will NOT mandate how exposed congestion should be
used. It will confine itself to the focused task of defining the
protocol for exposing congestion. However, it will strongly encourage
experiments into how this information can be used and will ultimately
produce guidance on the dos and don'ts of using this information. 

The proposed work items for this group are:
1)	An informational document giving the motivations for congestion
transparency and specifying the requirements for any protocol
2)	An experimental protocol for congestion transparency. This is
likely to be based upon the proposed re-ECN protocol as significant
research work has already been done to understand and test this protocol
and several implementations already exist.
3)	One or more informational documents reporting the results of
experiments on applications of the congestion transparency protocol.
Specifically these experiments will look at ways to ensure honest
disclosure of congestion information and means to ration congestion on a
per-user basis.

The initial goal is that all the output of the working group will be
informational or experimental, but once the experiments have been
completed then they will be used to determine if this approach should be
standardised within the IETF.