Subject: [re-ECN] BoF draft charter

From: <[email-masked]>
Date: Tue, 29 Sep 2009 11:27:49 +0100

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.

---

From: Michael Menth <[email-masked]>
Date: Tue, 29 Sep 2009 16:38:01 +0200

Hi Toby and all,

I am lacking a bit the structure in this text. I tried to improve this a 
bit.

Why congestion exposure?

So far, when congestion occurs, it can be made visible to the downstream 
path of a flow, e.g., through ECN marks. However, a node has no means to 
predict the congestion traffic is causing on its downstream path. Such 
information can be useful to fight against traffic that is excessively 
causing congestion further down its path, for accounting between ISPs, 
or many other purposes.

What is the WG planning to do?

The Congestion Exposure Working Group develops mechanisms so that an 
end-host or a proxy can add information about the expected overall 
congestion on a flow's path to the network layer of the Internet. Having 
also information in the network layer about the congestion caused on the 
upstream path of a flow, the downstream congestion can be quantified. 
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.

What is the expected impact of congestion exposure on other fields?

Related work ...

Regards,

Michael

[email-masked] schrieb:
> 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.
>
> 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 last paragraph distracts my attention from what the working group is 
about.

> 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.
>
> 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.
>
> 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.
>
> research work has already been done to understand and test this 
> protocol and several implementations already exist.
>
> disclosure of congestion information and means to ration congestion on 
> a per-user basis.
>
> completed then they will be used to determine if this approach should 
> be standardised within the IETF.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn
>   

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn