[re-ECN] ConEx BoF announcement text

[<[e-mail]>]

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.