Re: [re-ECN] BoF draft charter

[<[e-mail]>]

Should there be a "Draft Charter" entry on the wiki?

 

Toby

 

From: Eardley,PL,Philip,DEE1 R 
Sent: 08 October 2009 10:24
To: Moncaster,T,Toby,DEE1 R; '[e-mail]'
Subject: RE: [re-ECN] BoF draft charter

 

One follow-up on my original email. I realise that the sentence about
accountability should probably be deleted - as some of the mechanisms
building on top aren't really about accountability, eg traffic
engineering & performance metrics.

 

phil

 

-----Original Message-----
From: Moncaster,T,Toby,DEE1 R 
Sent: 07 October 2009 14:16
To: Eardley,PL,Philip,DEE1 R; '[e-mail]'
Subject: RE: [re-ECN] BoF draft charter

 

Thanks for that... One thing I was trying to avoid is too much
concentration on ECN. Whilst re-ECN is the current candidate proposal
for this others may well emerge (see thread from Matt Mathis for
instance). At this stage therefore I would quite like to qualify any
mentions of ECN (eg "for instance it might be based on ECN because...".
Also qualify any limitations (eg initially this will concentrate on
TCP).

 

I think there is still a little room for improvement but this is
starting to feel like a realistic charter to me...

 

I personally like the idea of having some formal work on deployment
considerations, but it would be important to scope it very tightly so it
didn't become open ended. Politically it might be nice to reference the
IAB work on this area...

 

Toby

 

From: Eardley,PL,Philip,DEE1 R 
Sent: 07 October 2009 12:48
To: Moncaster,T,Toby,DEE1 R; [e-mail]
Subject: RE: [re-ECN] BoF draft charter

 

I worked on this a bit - here's a revised suggestion.

- think should mention v4 & v6 in scope & TCP mod needed

- tried to spell out the work list more fully (don't think the actual
docs needs identifying yet)

- personally I don't think a requirements doc should be done, better is
a problem statement, which covers the scope of the problem we're solving
including any key assumptions. 

- I'm not sure about deployment considerations and intermediate steps
without ECN routers & without congestion exposure at the end hosts.
Interesting & important, but not sure if this is biting off too much?

- brought in a few words from bob's doc, problem statement i-d etc

- did a bit of reordering and re-wording 

 

Best wishes, 

phil

 

 

Congestion Exposure is a proposed new IETF activity to enable congestion
to be exposed within the network layer of the Internet. In particular it
will expose both the congestion-so-far and the expected rest-of-path
congestion in the IP header of each packet. Congestion exposure brings
with it a number of potential uses and benefits, as discussed briefly
below.

 

The internet is all about sharing capacity between multiple users, in
particular where the total bandwidth demand exceeds a link's capacity.
This leads to congestion, which is today managed by a combination of the
(voluntary) TCP algorithm and DPI boxes in ISP networks. It is
increasingly recognised that in today's internet this leads to issues
from technical, business and regulatory viewpoints [ref problem
statement, p2pi workshop]. At heart the problem is that the internet
lacks a system for accountability for causing congestion -
accountability for end users to networks, networks to networks, and
networks to end users. The key new metric proposed is that packets carry
information about the rest-of-path congestion, so any node can see the
congestion it causes others by sending or forwarding traffic. This
supplements the existing information from ECN about the
congestion-so-far, so any node can see the congestion that has already
been caused by the traffic it gets. 

 

Many mechanisms can be built on top of exposed congestion information.
Those suggested include: congestion policing at network ingresses,
inter-domain SLAs, end-to-end QoS, bandwidth sharing among users,
traffic engineering. The WG will encourage experiments on such
mechanisms, but it will not define them.

 

The main proposed item of work is to define the basic protocol that
exposes the expected rest-of-path congestion in the IP header - both v4
& v6 will be considered. The defined protocol should work with minimal
changes to the existing network, in particular it should work with
unmodified routers; the base assumption is that ECN is enabled, although
an intermediate scenario with non-ECN routers should also be considered.
Also required is a change to the transport protocol to feedback
congestion information from the receiver to sender - only TCP will be
considered. Further, the WG will consider an intermediate step with a
proxy mechanism in the network acting on behalf of unmodified end hosts
<is this widening the scope too much??> 

 

A strong candidate for this protocol is re-ECN [ref], as significant
research work has already been done and several implementations exist.
But the WG is expected to redesign and thoroughly test this alongside
any alternative proposed.

 

Congestion Exposure builds on ECN and complements other work at the IETF
and IRTF. LEDBAT & ICCRG are looking at new approaches to controlling
bulk data transfer rates; congestion exposure would provide better
information so that they could work more effectively. 

 

The proposed work items are:

*      Motivations for congestion exposure - the problems it could
address

*      A protocol for congestion exposure. 

*      Threat analysis

*      Guidelines for using the congestion exposure protocol (metric?);
it will be updated as a result of experience from the experiments

*      Reports of the results of experiments on uses of the congestion
exposure protocol

*      Deployment considerations <widens scope too much??>

 

The initial goal is that all the output of the working group will be
informational or experimental. However, if when the documents are ready
the technology seems mature enough, the WG will consider if it is
appropriate to ask the IESG to advance the document as a Proposed
Standard. 

 

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of [e-mail]
Sent: 29 September 2009 11:28
To: [e-mail]
Subject: [re-ECN] BoF draft charter

 

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.