[re-ECN] FW: ConEx BoF announcement text

[<[e-mail]>]

 

Suggested edited version (slightly shorter and it moves references to
re-ECN further towards the end. Also tries to tighten up the text a
bit):

 

Congestion Exposure (ConEx) is a proposed new IETF activity that reveals
congestion along the forwarding path of the Internet. By revealing the
expected congestion in the IP header of every packet, congestion
exposure provides a new generic network capability. We believe such
information could be used for many purposes, including congestion
policing, accountability and inter-domain SLAs. It may also open new
approaches to QoS and traffic engineering.

 

The Internet is, in essence, about pooling and sharing resources. This
has been paramount to its success and has traditionally been managed
through the voluntary use of TCP congestion control.  However, TCP alone
is unable to prevent bandwidth intensive applications, such as
peer-to-peer or streaming video, from causing enough congestion to
severely limit the user-experience of many other end-hosts.  This has
led ISPs to deploy ad-hoc solutions such as volume accounting, rate
policing and deep packet inspection in an attempt to distribute capacity
differently. Such practices are leading to calls for government
regulation as well as stifling innovation at the transport and
application layer (see for example, the problem statement I-D (ref
below) and RFC5594).

 

We believe these problems stem from the lack of accountability for
causing congestion at the network layer. We propose a metric where all
IP packets carry information about the expected rest-of-path congestion,
so that any network node may estimate how much congestion it will cause
by forwarding traffic. This will allow network operators to count the
volume of congestion about to be caused as easily as the volume of bytes
in any aggregate of traffic. Once ISPs can see rest-of-path congestion,
they can actively discourage users from causing excessive congestion,
encourage other networks to control the congestion their customers
cause, and more meaningfully differentiate between the qualities of
services offered by potential connectivity partners. Meanwhile end-hosts
can be freed from rate restrictions so long as they control the overall
congestion they cause. 

 

The purpose of this BoF is to explore whether the IETF community agrees
this lack of congestion exposure is a problem and to gauge the support
for and viability of pursuing an IETF activity to define a basic
protocol to expose the expected rest-of-path congestion in the IP
header.  Any such protocol should work with minimal changes to the
existing network; in particular it should work with unmodified routers.
There is already one existing proposal that builds on ECN to provide
rest-of-path congestion information in every IP header and other
proposals may come forward.

 

If supported, an eventual WG would focus on developing such a protocol
as its main work item.  Additional work items could include detailing
the motivations for congestion exposure, a threat analysis of the
protocol, providing feedback on experimental trials and describing
deployment considerations. Importantly, the proposed WG would encourage
experimentation but not deliberate on how congestion exposure should be
used: our concern would be how flexibly the resulting protocol can
support differing needs at run-time, rather than dictating a particular
usage at design time.

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf
Of [e-mail]
Sent: 16 October 2009 11:28
To: [e-mail]
Subject: [re-ECN] ConEx BoF announcement text

 

Here's a slightly revised version of the announcement text - thanks to
Joao and everyone who worked on it.

 

The main change was to re-write the last 2 paras from the perspective of
the BoF. I also deleted the claim that the work should be
transport-agnostic, as I find 'transport' an ambiguous word & also think
the substantive point is already made by saying the congestion is
revealed in the IP header.

 

Please send any further suggestions asap, so we can circulate to other
mailing lists later today

 

Thanks

Phil & Leslie 

 

---

 

Congestion Exposure (ConEx) is a proposed new IETF activity to enable
congestion to be exposed along the forwarding path of the Internet. By
revealing expected congestion in the IP header of every packet,
congestion exposure provides a generic network capability which allows
greater freedom over how capacity is shared.

 


An existing proposal, building on ECN to reveal "rest-of-path"
information into the IP header, has already demonstrated how congestion
exposure can give an incentive to control one's impact on the network
beside TCP congestion-control. We believe this "congestion exposure"
information may be used for many purposes, including congestion
policing, accountability and inter-domain SLAs. It may also open new
approaches to QoS and traffic engineering.

 

The Internet is, in essence, about pooling resources. The ability to
share capacity has been paramount to its success and has traditionally
been managed through the voluntary use of TCP congestion control.
However, TCP alone is unable to prevent bandwidth intensive
applications, such as peer-to-peer or streaming video, from causing
enough congestion to severely limit the user-experience of many other
end-hosts.  This has led ISPs to deploy ad-hoc solutions such as volume
accounting, rate policing and deep packet inspection in an attempt to
distribute capacity differently. The consequences of such practices are
increasingly leading to calls for government regulations and stifling
innovation at the transport and application layer (see for example, the
problem statement I-D (ref below) and RFC5594).

 

We believe these problems stem from the lack of a network-layer system
for accountability -- among all parties -- for sending traffic which
causes congestion. We propose a metric where IP packets carry
information about the expected rest-of-path congestion, so that any
network node may estimate how much congestion it is likely to cause by
forwarding traffic. A network operator can then count the volume of
congestion about to be caused by an aggregate of traffic as easily as it
can count the volume of bytes entering its network today. Once ISPs can
see rest-of-path congestion, they can actively discourage users from
causing large volumes of congestion, discourage other networks from
allowing their users to cause congestion, and more meaningfully
differentiate between the qualities of services offered from potential
connectivity partners. Meanwhile end-hosts may be freed from rate
restrictions where their traffic causes little congestion. 

 

The purpose of the BoF is to explore the support for and viability of
pursuing an IETF activity to define a basic protocol to expose the
expected rest-of-path congestion in the IP header.  Any such protocol
should work with minimal changes to the existing network, in particular
it should work with unmodified routers.

 

If supported, an eventual WG would focus on the development of that
protocol as its main work item.  Additional work items could include
detailing the motivations for congestion exposure, a threat analysis of
the subsequent protocol, providing feedback on experimental trials and
describing deployment considerations. Importantly, the proposed WG would
encourage experimentation but not deliberate on how congestion exposure
should be used: our concern would be how flexibly the resulting protocol
can support differing needs at run-time, rather than dictating a
particular usage at design time.