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

[Bob Briscoe <[e-mail]>]

Leslie,

I like the announcement text now (it was pretty good already).

I have a few suggestions that seem like nits, but they are important (to me).

I'm assuming you "hold the token" on the text at the mo. So I've 
pasted it from the wiki below, and added my comments.

============================================================================
>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,

s/every packet/packets/

[[[Reasoning: We shouldn't imply we have ambitions to ever make all 
Internet traffic expose congestion. I defined the re-ECN protocol so 
re-ECN and non-re-ECN packets can be distinguished. Then different 
apps can choose to use it or not. And different ISPs can choose to 
separately account for these two main types of traffic (or not). This 
is what we should mean by permanent partial deployment.

For example, Sally Floyd was much less concerned about re-ECN once I 
had made this design goal clear.

Anyway, on practicality grounds, an ISP can't force all IP traffic to 
use ConEx, particularly if we've only initially defined it for some 
transports like TCP and not others like DNS/UDP. Obviously, if an ISP 
uses congestion exposure in the future to limit heavy sources of 
congestion, then the ISP is likely to severely limit non-re-ECN 
traffic. But we should leave that up to each ISP.
]]]

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

s/bandwidth intensive applications/applications transferring high 
traffic volumes/

[[[Reasoning: TCP *can* limit bandwidth, but it cannot arbitrate 
continuously heavy use of bandwidth over time.
]]]

>such as peer-to-peer or streaming video, from causing enough congestion

i/over time /

>to severely limit the user-experience of many other end-hosts.

s/user-experience of many other end-hosts/experience of many other users/

[[[hosts don't have user-experiences
]]]

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

s/sending/forwarding/

[[[Reasoning: applies equally to networks or senders
]]]

>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

d/actively /

[[[Reasoning: passively (e.g. pricing) or actively (e.g. policing)
]]]

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

i/In this environment the self-imposed constraint of TCP-friendliness 
could be relaxed, allowing a richer variety of application behaviours 
to evolve that would still prevent congestion collapse./

[[[Your original had wording around this idea that has got lost in 
translation.]]]


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

d/Any such protocol should work with minimal changes to the existing 
network, in particular it should work with unmodified routers./

[[[Reasoning: A BoF announcement shouldn't contain strong 
requirements-text. A little lower down, I've introduced text that 
conveys the same sentiment without making it a strong requirement.
]]]

>There is already one existing proposal that builds on ECN to provide 
>rest-of-path congestion information in every IP header

s/every IP header/IP headers/

>and other proposals may come forward.
>
>If supported, an eventual WG would focus on the development of that protocol

s/that protocol/its chosen congestion exposure protocol/

>as its main work item.

i/The chosen protocol will need to be deployable with minimal changes 
to the existing Internet and compare well against the existing 
proposal, which works with unmodified routers./

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

s/providing feedback on/reporting on/

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



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