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

[<[e-mail]>]

I found bob's new version much better, especially the more positive
slant of the 'proposed para 4'.

My only 2 minor comments:-
<< However, TCP doesn't account for how much an application occupies
capacity over time.>>
I suggest tweaking this to say "how much a user or applications
occupies"

<<These ad-hoc practices can stifle innovation at the transport and
application layer ... This in turn has increasingly led to calls for
government regulations>>
I suggest tweaking this to say "These ad-hoc practices can stifle
innovation at the transport and application layer, and have led to calls
for government regulations [refs]".

> -----Original Message-----
> From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
> Sent: 26 October 2009 16:06
> To: Leslie Daigle
> Cc: Eardley,PL,Philip,DEE1 R; [e-mail]
> Subject: Re: [re-ECN] FW: ConEx BoF announcement text
> 
> 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