[Iccrg] Congestion Exposure (CONEX) Bof in Hiroshima

[philip.eardley]

An alert of the Congestion Exposure (CONEX) Bof in Hiroshima - currently
scheduled for Tues 15.20 - 18.10. 

Best wishes,

Philip Eardley & Leslie Daigle (BoF Chairs)

 

Congestion Exposure (CONEX)

(was re-ECN)

 

Description

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. 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 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. 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 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.

 

Related Internet-Drafts include:  

http://www.ietf.org/id/draft-moncaster-congestion-exposure-problem-01.tx
t 

http://www.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp-08.txt 

http://www.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp-motivation-01.txt


 

Other useful reference material:  

http://www.bobbriscoe.net/projects/refb/FairerFasterWP.pdf  

 

Mailing list for discussion: 

re-ecn at ietf.org   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20091019/c161801b/attachment.html