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

[Leslie Daigle <[e-mail]>]

Hi,

I'll confess to having been lazy about updating the rest of hte page :-) 
  I'll look at it again during the week, or feel free to tidy those up 
if you have a mo.  However, with respect to the duplication -- that was 
somewhat intentional.  My goal was to have a uniform chunk of text for 
the BoF, *including* references that can (and will) get circulated on 
mailing lists.

Thanks,
Leslie.

Bob Briscoe wrote:
> 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

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[e-mail]
-------------------------------------------------------------------