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

[Bob Briscoe <[e-mail]>]

Leslie,

OK, in that case, I'd rather remove the duplicate refs from lower down.
I'll do that now.

I'll add a brief word on what each reference is (using the words 
deleted from the end).

I'll also add a ref to the page for subscribing to the list, not just 
sending to it.


Bob

At 17:55 18/10/2009, Leslie Daigle wrote:

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

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design