IETF Congestion Exposure (CONEX) BoF in Hiroshima

[Dave Farber <dave () farber net>]

Begin forwarded message:

> From: Jason Livingood <jason_livingood () cable comcast com>
> Date: October 26, 2009 15:56:16 EDT
> To: Dave Farber <dave () farber net>
> Subject: IETF Congestion Exposure (CONEX) BoF in Hiroshima

> Dave – May be of interest to IPers, especially if anyone is consider 
> ing whether or not to attend the upcoming IETF meeting.  It is parti 
> cular interesting given recent discussion of QoS and traffic enginee 
> ring on this list.
>
> - Jason
>
> ------ Forwarded Message
> http://trac.tools.ietf.org/area/tsv/trac/wiki/re-ECN
>
> Congestion Exposure BoF (ConEx)
> Tuesday, November 11, 2009 --- 1520 – 1810 local time
> Hiroshima Japan – 76th IETF Meeting
>
> BoF Chairs
> Leslie Daigle & Philip Eardley
>
> 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  
> packets, 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 over time to severely limit  
> the user-experience of many other users. 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 <http://tools.ietf.org/html/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 sending or 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 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 IP headers and other proposals may  
> come forward.
>
> If supported, an eventual WG would focus on the development of its  
> chosen congestion exposure protocol as its main work item. The  
> chosen protocol will need to be deployable with minimal changes to  
> the existing Internet, preferably working with unmodified routers.  
> Additional work items could include detailing the motivations for  
> congestion exposure, a threat analysis of the subsequent protocol,  
> reporting 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:
>
> ConEx Problem statement:
>  http://tools.ietf.org/id/draft-moncaster-congestion-exposure-problem
>  http://tools.ietf.org/html/draft-tschofenig-conex-ps
> re-ECN protocol spec:
>  http://tools.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp
> re-ECN motivation:
>  http://tools.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp-motivation
>
> Other useful reference material:
>
> Overview: problem & solution (7pp):
>  http://www.bobbriscoe.net/projects/refb/FairerFasterWP.pdf
>
> Mailing list for discussion:     re-ecn () ietf org
> Subscribe:  https://www.ietf.org/mailman/listinfo/re-ecn



-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com