NNSquad - Network Neutrality Squad
[ NNSquad ] IETF Congestion Exposure (CONEX) BoF in Hiroshima
----- Forwarded message from Dave Farber <dave@farber.net> ----- Date: Mon, 26 Oct 2009 16:07:37 -0400 From: Dave Farber <dave@farber.net> Subject: [IP] IETF Congestion Exposure (CONEX) BoF in Hiroshima Reply-To: dave@farber.net To: ip <ip@v2.listbox.com> 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 considering > whether or not to attend the upcoming IETF meeting. It is particular > interesting given recent discussion of QoS and traffic engineering 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 ----- End forwarded message -----