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

[Bob Briscoe <[e-mail]>]

Leslie,

I realised what I didn't like. It was saying "TCP can't bash p2p" 
which implied we want something that can. I've changed it round (& 
it's a few bytes shorter):

<BB_proposed_para2>
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 doesn't account for how much an 
application occupies capacity over time. This has led ISPs to deploy 
various ad-hoc mechanisms such as volume accounting, rate policing 
and deep packet inspection. These try to protect the experience of 
the majority of users by limiting persistent traffic such as 
peer-to-peer file-sharing or video streaming. These ad-hoc practices 
can stifle innovation at the transport and application layer (see for 
example, the problem statement I-D referred to below and RFC5594). 
This in turn has increasingly led to calls for government regulations.
</BB_proposed_para2>

The whole thing has a relentlessly negative tone I'm afraid. It's all 
about using ConEx to stop stuff. It's not getting across that we're 
giving ISPs a tool to encourage things like LEDBAT and potentially 
much better LEDBAT++s. And faster transports in the future. And apple 
pie. And not having to limit volume unnecessarily. And not having to 
limit bit-rate unnecessarily. And doves, and blossom and running 
mountain streams ...

<2nd_Half_of_para3_on_wiki>
Once ISPs can see rest-of-path congestion, they can 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.
</2nd_Half_of_para3_on_wiki>

<BB_proposed_para4>
<P><!--insert para break-->
Once ISPs can see rest-of-path congestion, they will no longer need 
to unnecessarily limit volume or bit-rate or p2p just in case it 
leads to congestion. They can limit only those users who cause large 
volumes of congestion, and they can discourage other networks from 
allowing their users to cause congestion. This will allow ISPs to 
encourage transports like LEDBAT that send large amounts of volume 
while causing little congestion. And end-hosts can be freed from peak 
rate restrictions when their traffic causes little congestion.
</BB_proposed_para4>

I dropped "And they can more meaningfully differentiate between the 
qualities of services offered by potential connectivity partners." I 
couldn't make it fit the flow as it started on a new concept. It is 
also off the "one main message".


Bob

At 21:29 25/10/2009, Leslie Daigle wrote:

>Hi Bob,
>
>I've no issue with chucking the proposed text, if there's 
>better.  But, I think the fact that we (collectively) have been 
>stumbling around that para and evidently not winding up in the same 
>place is evidence that we need to get text on the table that works 
>for everyone, and the original isn't it.  (Not for the announcement, 
>at this point, but for a draft charter, the problem document, and so on).
>
>So, I hope you're better rested, as you read this, and are willing 
>to take another stab at sentence #2 :-)      I would (and will, if 
>need be), but I think that would be the longer road to convergence...
>
>Leslie.
>
>Bob Briscoe wrote:
>>Leslie,
>>It would be much better to leave it as it is than make these changes, IMHO.
>>It's got more confusing and worserer (see inline comments later).
>>I was trying to write something to replace that middle sentence, 
>>but I'm having trouble staying awake, so I thought I had better 
>>just say it would not be a good idea to do the proposed update. 
>>I'll try some text manyana.
>>Also inline...
>>At 03:59 24/10/2009, Leslie Daigle wrote:
>>>Hi Bob,
>>>
>>>I didn't change that para, not because it seemed to be perfect, 
>>>but because there seem still to be confusion about how to improve it.
>>>
>>>I think the current proposal (per my last message, and certainly 
>>>still subject to improvement!) is:
>>>
>>><on the wiki, to be replaced:>
>>>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 over time to 
>>>severely limit the user-experience of many other users. 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).
>>></on the wiki>
>>>
>>>
>>><proposed>
>>>The Internet is, in essence, about pooling resources. The ability to
>>>share capacity has been paramount to its success and currently 
>>>relies on the voluntary use of TCP congestion control. However, 
>>>this assumes all application requirements are the same, and 
>>>congestion can be avoided by ensuring orderly and fair (on 
>>>average) access to bandwidth.
>>not the problem
>>
>>>This is does not generally work for peer-to-peer or streaming 
>>>video applications.
>>It works, it's just aiming for the wrong shares.
>>
>>>In order to avoid congestion from such applications, more 
>>>aggressive control is required in some circumstances than is 
>>>provided by standard TCP congestion control.
>>'Aggressive' is usually used to mean the congestion control pushes 
>>harder against others, taking more bandwidth. For p2p *less* 
>>aggressive endpoint control is required (e.g. LEDBAT). [Perhaps you 
>>meant the *network* has to be more aggressive against p2p & 
>>streaming? If so, that sounds like we're advocating app-specific 
>>network control (which we're most definitely not).]
>>
>>>Networks are currently unable to accurately detect these 
>>>applications' traffic
>>They can - unfortunately.
>>
>>>or the circumstances in which additional control should be applied.
>>Again, 'additional' sounds like we're arguing for app-specific, 
>>which we're not.
>>
>>>The consequences of such practices are increasing calls for 
>>>government regulation and stifling innovation at the transport and 
>>>application layer (see for example, the problem statement I-D (ref 
>>>below) and RFC5594).
>>></proposed>
>>But thanks for trying.
>>Cheers
>>
>>Bob
>>
>>>Though I'm suspecting that some instances of "congestion" should 
>>>be replaced by "performance".
>>>
>>>Leslie.
>>>
>>>Bob Briscoe wrote:
>>>>Leslie,
>>>>I accept all the changes you've made except one, which we really 
>>>>must stop saying.
>>>>1/ "However, TCP alone is unable to prevent bandwidth intensive 
>>>>applications"
>>>>TCP *does* prevent high bandwidth apps. That's the problem.
>>>>And implying intensive bandwidth usage needs to be prevented is 
>>>>rubbish marketing for the idea behind ConEx, given it *enables* 
>>>>higher bandwidth apps.
>>>>I believe congestion exposure will enable an Internet where high 
>>>>bandwidth and high volume apps can co-exist optimally. I want to 
>>>>encourage high bandwidth apps *and* high volume apps, not prevent either.
>>>>I sometimes think there really are people on this list who 
>>>>believe that too much use of the Internet is the problem. Or 
>>>>congestion is the problem. No. No. No. Rubbish capacity sharing is the problem.
>>>>This is the same point as moving away from TCP-friendly, which is 
>>>>what LEDBAT aims for. LEDBAT deliberately allows interactive 
>>>>stuff to go faster while background stuff temporarily goes 
>>>>slower. That is the opposite of TCP-friendly, which is better overall.
>>>>Data point: In the transport area plenary in March '09, Matt 
>>>>Mathis asked for a hum on "Is TCP-friendly a way forward?".
>>>>Yes: zero; No: most of the hall.
>>>>[It's minuted as 'all hummed no' but I'd say that was 
>>>>over-enthusiastic minute-taking as I'm sure there were plenty of 
>>>>the obligatory silent observers you get these days at the IETF, 
>>>>who were sitting on their hands 
>>>><http://www.ietf.org/proceedings/74/minutes/tsvarea.txt>]
>>>>With congestion exposure, we will be able to have weighted 
>>>>congestion control. Then we should be able to repeat the LEDBAT 
>>>>trick recursively as different size flows arrive. Ie. imagine 
>>>>three types of flows co-existing:
>>>>- small foreground flows
>>>>- medium middleground flows
>>>>- larger background flows
>>>>The larger background can be background to the medium 
>>>>middleground, and both can be background to the small foreground. 
>>>>This can continue with any number of recursions. All transfers 
>>>>complete much faster, except the very largest flows which should 
>>>>complete in not much more time than they do now.
>>>>2/ User experience: I agree; hard to quantify, but not 
>>>>impossible. It's a mix of faster at same price / cheaper at same quality.
>>>>Aspects of user experience that are really hard to quantify: less 
>>>>complexity / more future innovation.
>>>>
>>>>Bob
>>>>At 02:55 20/10/2009, Leslie Daigle wrote:
>>>>
>>>>>Bob,
>>>>>
>>>>>First -- thanks for making the suggestions as marked up 
>>>>>text:  it makes it easier for all of us to track what is (and is 
>>>>>not) changing in the text.
>>>>>
>>>>>Having seen no further discussion of the changes, I've made the 
>>>>>changes as follows.  I've also indicated where I've not made the 
>>>>>changes, in case there is further discussion (in-line):
>>>>>
>>>>>
>>>>>[e-mail] wrote:
>>>>>>Bob
>>>>>>Some (personal) comments in-line
>>>>>>Best wishes,
>>>>>>phil
>>>>>>-----Original Message-----
>>>>>>From: [e-mail] [mailto:[e-mail]] On Behalf
>>>>>>Of Bob Briscoe
>>>>>>Sent: 18 October 2009 19:47
>>>>>>To: Leslie Daigle
>>>>>>Cc: [e-mail]
>>>>>>Subject: Re: [re-ECN] FW: ConEx BoF announcement text
>>>>>>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/
>>>>>
>>>>>Done
>>>>>
>>>>>>[phil] agree with your change
>>>>>>[[[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/
>>>>>
>>>>>Not done -- agree with Phil.
>>>>>
>>>>>>[phil] personally I don't find your version any more or less clear than
>>>>>>the current text. maybe a 3rd version is needed!
>>>>>>[[[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 /
>>>>>
>>>>>Done.
>>>>>
>>>>>>
>>>>>>>to severely limit the user-experience of many other end-hosts.
>>>>>>s/user-experience of many other end-hosts/experience of many other
>>>>>>users/
>>>>>>[phil] ok
>>>>>
>>>>>Done.  As a bit of a gripe:  "user experience" is not quantifiable.
>>>>>It would be nicer if we could actually express this in terms of 
>>>>>some other quantifiable impact at the end hosts.  I am not 
>>>>>inspired to suggestion, however.  (So, I did the mod as described :-) ).
>>>>>
>>>>>>[[[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/
>>>>>>[phil] maybe this depends whether you think forwarding is a subset or
>>>>>>sending, sending is a subset of forwarding, or neither. Perhaps the
>>>>>>easiest solution is to say "sending or forwarding"
>>>>>
>>>>>Changed to sending or 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 /
>>>>>
>>>>>Done.
>>>>>
>>>>>>[phil] ok
>>>>>>[[[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./
>>>>>>[phil] if this is inserted, there is no point having the last sentence
>>>>>>["Meanwhile..."], as they say the same thing. I don't care much between
>>>>>>them.
>>>>>>[[[Your original had wording around this idea that has got lost 
>>>>>>in translation.]]]
>>>>>
>>>>>No change made -- I think positing TCP-friendliness could be 
>>>>>relaxed is probably overreaching (happy to be educated 
>>>>>otherwise), and largely think the rest is covered in the "Meanwhile" sentence.
>>>>>
>>>>>>
>>>>>>>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./
>>>>>>[phil] I have no strong preference where this text appears
>>>>>>[[[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.
>>>>>>]]]
>>>>>
>>>>>Done -- I do think the BoF announcement should give some sense 
>>>>>of boundaries that exists.  Having said that, I don't care where 
>>>>>it is, and am happy to migrate it closer to the proposal text.
>>>>>
>>>>>>
>>>>>>>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/
>>>>>
>>>>>Done.
>>>>>
>>>>>>
>>>>>>>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./
>>>>>
>>>>>I inserted:
>>>>>
>>>>>"The chosen protocol will need to be deployable with minimal 
>>>>>changes to the existing Internet, preferably working with unmodified routers."
>>>>>
>>>>>I deleted the competition with the existing proposal -- either 
>>>>>that's obvious, or something else is at play from which the 
>>>>>BoF/WG should not be constrained, so it seemed an unnecessary 
>>>>>restriction in the text.
>>>>>
>>>>>>
>>>>>>>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/
>>>>>
>>>>>Done.
>>>>>
>>>>>>[phil] ok
>>>>>>
>>>>>>>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.
>>>>>
>>>>>
>>>>>Thanks,
>>>>>Leslie.
>>>>>
>>>>>>
>>>>>>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
>>>>>>_______________________________________________
>>>>>>re-ECN mailing list
>>>>>>[e-mail]
>>>>>>https://www.ietf.org/mailman/listinfo/re-ecn
>>>>>
>>>>>--
>>>>>
>>>>>-------------------------------------------------------------------
>>>>>"Reality:
>>>>>      Yours to discover."
>>>>>                                 -- ThinkingCat
>>>>>Leslie Daigle
>>>>>[e-mail]
>>>>>-------------------------------------------------------------------
>>>>________________________________________________________________
>>>>Bob Briscoe,                                BT Innovate & Design
>>>
>>>--
>>>
>>>-------------------------------------------------------------------
>>>"Reality:
>>>      Yours to discover."
>>>                                 -- ThinkingCat
>>>Leslie Daigle
>>>[e-mail]
>>>-------------------------------------------------------------------
>>________________________________________________________________
>>Bob Briscoe,                                BT Innovate & Design
>
>--
>
>-------------------------------------------------------------------
>"Reality:
>      Yours to discover."
>                                 -- ThinkingCat
>Leslie Daigle
>[e-mail]
>-------------------------------------------------------------------

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design