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

[<[e-mail]>]

Inline...

> -----Original Message-----
> From: Eardley,PL,Philip,DEE1 R
> Sent: 21 October 2009 13:50
> To: Moncaster,T,Toby,DEE1 R; [e-mail]
> Cc: [e-mail]
> Subject: RE: [re-ECN] FW: ConEx BoF announcement text
> 
> Thanks toby & Richard, useful inputs.
> 
> I think the full explanation is a bit long for the wiki, but should be
> added to eg the problem statement. I think it would be very nice if the
> problem statement could give a separate ISP & applications/users
> perspective on "why conex?" - not sure if this would be covered by the
> 'use cases' section?

I am working on a new version and may try and incorporate something like this (so long as it fits the structure)


> 
> Anyway, back to the wiki text.
> 
> Here's the current para under discussion:
> 
> << 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).
> >>

> 
> how about this [first 2 sentences unchanged]:-
> 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, now some bandwidth intensive applications, such as peer-to-
> peer or streaming video, severely limit the experience of other
> applications -- TCP alone [or today's TCP?] is no longer sufficient,
> because its design assumptions no longer apply [or fully apply?]. This
> has led ISPs to deploy ad-hoc solutions....

I think I would rather say something slightly different about TCP. How about making the whole:

" The Internet is, in essence, about pooling resources. The ability to
share capacity has been paramount to its success and has traditionally
relied on the voluntary use of TCP congestion control. However, TCP may not be the most suitable algorithm for applications such as peer-to-peer or streaming video that break some of its fundamental design assumptions. Such applications are able to cause enough congestion over time to severely impair the quality of experience of other users. This has led some ISPs to deploy ad-hoc solutions such as volume accounting, rate policing or deep packet inspection in an attempt to distribute capacity differently. 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)."


> 
> 
> The next para talks about the conex approach to solving this, first
> from the isp perspective and then applications perspective, ending with
> the sentence:-
> << Meanwhile end-hosts may be freed from rate restrictions where their
> traffic causes little congestion.>>
> 
> how about this:-
> Meanwhile end-hosts may be freed from TCP's rate restrictions. For
> example, applications could transmit faster where their traffic causes
> little congestion.

Or "Meanwhile end-hosts can be freed from TCP's one-size fits all rate restrictions. Applications can go as fast as they wish so long as they control the level of congestion they cause."


> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of [e-mail]
> Sent: 21 October 2009 12:43
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [re-ECN] FW: ConEx BoF announcement text
> 
> The actual logic should go something like: TCP works for some
> applications but not all applications. But TCP has a hallowed status.
> This causes problems in the network with some users getting more than
> their ISPs believe they should. The ISPs are unable to actually see
> which users are causing problems because this is concealed from them.
> Making congestion visible would allow the impact of different users to
> be seen properly.
> 
> This collapses into something like "TCP is not the answer to everything
> and is not really relevant to this debate. What is relevant is the
> impact you have on everyone else which is why ISPs are trying to impose
> controls based on flow rate or volume. But congestion is the actual
> metric that matters. So we need to reveal this to the network not
> conceal it at end systems. This would allow the control to be based on
> congestion."
> 
> We probably also need a story about why users would benefit from this.
> After all someone naïve will think "why should I say how much
> congestion I cause if it just means I will be targeted by my ISP". And
> of course there are 2 parts to the answer: "It is better that your ISP
> targets you on congestion than volume or rate because you can then do
> clever things like LEDBAT to improve your network performance whilst
> cutting your congestion" and "If everyone else also reveals congestion
> then you benefit from the collective effect of everyone being
> accountable for this congestion" In other words this reverses the
> tragedy of the commons (would that make it the comedy of the commons?
> ;)
> 
> And yes, the fact that TCP congestion control is not always appropriate
> is a really key point. In fact perhaps what should be highlighted about
> congestion exposure is that if you are being honest about the
> congestion you cause it doesn't really matter what congestion control
> you use - everyone else is able to see how you are actually reacting...
> 
> Toby
> 
> PS. Sorry for the rambling nature of this email - I have been giving my
> mind free reign...
> 
> > -----Original Message-----
> > From: Leslie Daigle [mailto:[e-mail]]
> > Sent: 20 October 2009 22:31
> > To: Moncaster,T,Toby,DEE1 R
> > Cc: Briscoe,RJ,Bob,XVR9 BRISCORJ R; [e-mail]
> > Subject: Re: [re-ECN] FW: ConEx BoF announcement text
> >
> >
> > Hi Toby,
> >
> > Sorry for not calling this out in the earlier notes.
> >
> > I'm concerned that rephrasing is getting a bit circular in logic --
> "we
> > need congestion exposure because TCP can't do adequate congestion
> > exposure".    That kind of collapses to "we need congestion exposure"
> > without providing a basis for it.
> >
> > Generally, to the whole list -- let's step back and look at the set
> of
> > sentences.
> >
> >
> > 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.
> >
> >
> >
> >
> > Maybe we need to unpack it a bit, and consider Bill's suggestion of
> > s/user/application/.
> >
> > How can we express the functional assumptions of TCP congestion
> control
> > that are violated by the nature of P2P and video applications?  And,
> > what is the objective description of the impact of TCP congestion
> > control on this different traffic type?
> >
> > It's not that TCP congestion control is broken or failing, it's not
> > that
> > these applications are wrong or evil, TCP congestion control just
> isn't
> > applicable.
> >
> > How can we capture that?
> >
> > Leslie.
> >
> >
> >
> > [e-mail] wrote:
> > > Leslie,
> > >
> > > I actually replied yesterday afternoon (UK time) with a possible
> > > alternative wording for the snippet of text that both Bob and Phil
> > felt
> > > was wrong. Having read the new version I have had another go:
> > >
> > > Current version (after your changes):
> > >
> > > " 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."
> > >
> > > My suggested alternative:
> > >
> > > "However TCP alone is unable to prevent some users from causing
> > > sufficient congestion over time to significantly impair the quality
> > of
> > > experience of other users."
> > >
> > > OR
> > >
> > > "However TCP alone is unable to prevent some users from creating
> > > excessive congestion over time leading other users to experience
> > > severely reduced network performance."
> > >
> > > I tried to find different words for user experience but it is hard.
> > The
> > > problem with pinning it down too tightly is that the impact is
> > different
> > > on each user and covers things such as increased jitter, delays to
> > > downloads, stuttering video, unresponsive websites, etc. There is
> no
> > one
> > > measure that sums up all those effects other than a vague feeling
> > that
> > > the overall experience is better or worse.
> > >
> > > Toby
> > >
> > >
> > >> -----Original Message-----
> > >> From: [e-mail] [mailto:[e-mail]] On
> > >> Behalf Of Leslie Daigle
> > >> Sent: 20 October 2009 02:55
> > >> To: Briscoe,RJ,Bob,XVR9 BRISCORJ R
> > >> Cc: [e-mail]
> > >> Subject: Re: [re-ECN] FW: ConEx BoF announcement text
> > >>
> > >>
> > >> 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:re-ecn-
> [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]
> > >> ------------------------------------------------------------------
> -
> > >> _______________________________________________
> > >> 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