Re: [re-ECN] FW: ConEx BoF announcement text

[Bob Briscoe <[e-mail]>]

Leslie,

Thanks for this.

Had you noticed that most of the linked refs are repeated a little 
further down the page (and one or two of the original links need to 
point to revved versions)?

Shall I tidy up, or would you rather?

Comments (minor) on the text itself next.



Bob

At 04:02 17/10/2009, Leslie Daigle wrote:

>Hi,
>
>I've posted a description on the BoF wiki page:
>
>http://trac.tools.ietf.org/area/tsv/trac/wiki/re-ECN
>
>I think I mostly followed the structural edits, but not the wording 
>changes within sentences, because I felt there were important (if 
>subtle) changes that I wasn't convinced about/would want further 
>input from the list for.   But -- it's a wiki.  We can change the 
>text, if there's need to do so!
>
>Thanks,
>Leslie.
>
>>
>>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.
>>
>>------------------------------------------------------------------------
>>_______________________________________________
>>re-ECN mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/re-ecn
>
>--
>
>-------------------------------------------------------------------
>"Reality:
>      Yours to discover."
>                                 -- ThinkingCat
>Leslie Daigle
>[e-mail]
>-------------------------------------------------------------------
>_______________________________________________
>re-ECN mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design