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

[Leslie Daigle <[e-mail]>]

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