Subject: [re-ECN] ConEx BoF announcement

From: João Taveira Araújo <[email-masked]>
Date: Mon, 12 Oct 2009 12:56:13 +0100

Hi,

We still need to produce an IETF wide announcement for the ConEx BoF. 
I've taken the last iteration of the draft charter, problem statement 
and BoF proposal and cut them down. Before bashing please take into 
account this announcement:

- is meant to drum interest, which is why the potential uses are stated 
in the first paragraph
- should not focus on technical solutions, so no mention of [re]ECN.

For clarity's sake we should be looking at keeping it relatively short. 
Further detail can be kept for the BoF charter.

Bash away,
Joao.
Congestion Exposure (ConEx) is a proposed new IETF activity to enable congestion to be exposed within the network layer of the Internet. By revealing expected congestion in the IP header of every packet, congestion exposure provides a generic network capability which simplifies resource allocation.  This information may in turn be used for multiple purposes, including congestion policing, inter-domain SLAs, end-to-end 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.  TCP alone however 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 lead ISPs to deploy ad-hoc solutions such as volume accounting, rate policing and deep packet inspection in an attempt to distribute capacity differently.  It is increasingly recognised that in today's internet this leads to issues from technical, business and regulatory viewpoints [ref problem statement, p2pi workshop].

The heart of the problem is that the internet lacks a system for accountability for causing congestion - accountability for end users to networks, networks to networks, and networks to end users.  The key new metric proposed is that packets carry information about the rest-of-path congestion, so any node can see the congestion it causes others by sending or 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 congestion, they can discourage users from causing large volumes of congestion, and they can discourage other networks from allowing their users to cause congestion.  

The main proposed item of work is to define the basic protocol that exposes the expected rest-of-path congestion in the IP header. The defined protocol should work with minimal changes to the existing network, in particular it should work with unmodified routers, and be transport-agnostic.  While the proposed WG will encourage experimentation with the new metric, it will not define in detail how exposed congestion should be used.

The proposed work items are:

- Motivations for congestion exposure - the problems it could address
- A protocol for congestion exposure.
- Threat analysis
- Guidelines for using the congestion exposure protocol (metric?)
- Reports of the results of experiments on uses of the congestion exposure protocol
- Deployment considerations

---

From: Matthew Ford <[email-masked]>
Date: Mon, 12 Oct 2009 14:56:06 +0100

Hi Joao,

This looks pretty good to me - a couple of comments:

Please s/internet/Internet

I think the final sentence of the third para could use a little work, 
perhaps:

Once ISPs can see rest-of-path congestion, they can accurately and 
precisely discourage users from causing large volumes of congestion, 
they can discourage other networks from allowing their users to cause 
congestion, and they can more meaningfully differentiate between the 
qualities of services offered from potential connectivity partners.

Mat

On 12/10/2009 12:56, João Taveira Araújo wrote:
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn

---

From: John Leslie <[email-masked]>
Date: Mon, 12 Oct 2009 11:26:53 -0400

Jo?o Taveira Ara?jo <[email-masked]> wrote:

> Congestion Exposure (ConEx) is a proposed new IETF activity to enable
> congestion to be exposed within the network layer of the Internet.

   I think the point is "exposed along the forwarding path" in the
network (IP) layer.

   Further, AFAIK what will be exposed is both "expected congestion" and
"congestion experienced so far". (This sounds like magic, of course, and
we should perhaps take some pains to convince readers it is merely
"sufficiently advanced technology" ;^)

> By revealing expected congestion in the IP header of every packet,

   Here's a good place to start dispelling the "magic" appearance.
AFAIK we don't intend to put a high-precision number in every packet,
but instead to put one bit in some fraction of packets sent, in
proportion to the congestion expected. The former sounds like magic;
the latter like advanced technology.

> congestion exposure provides a generic network capability which
> simplifies resource allocation.

   I'm not sure "simplifies" is correct -- instead I think we mean
"enables better resource allocation".

> This information may in turn be used for multiple purposes, including
> congestion policing, inter-domain SLAs, end-to-end QoS and traffic
> engineering.

   It's sounding like magic again... I don't think those should be run
together.

   For congestion policing, we might say something like
" 
" At any point along the forwarding path, such as a peering point, a
" congestion policing function could check whether the percentage of
" congestion-expected-marked packets exceeds the contracted percentage,
" and assess additional charges or refuse some of the traffic.

   The other items are too broad for me to wordsmith at this time...

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

   "TCP congestion-control", I think.

> TCP alone however 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 isn't the right emphasis, IMHO. Let me try to shift the emphasis:
" 
" Traditional TCP congestion-control, however, is proving ill-suited to
" the needs of bandwidth-intensive applications such as streaming audio
" and video. Similarly, background-file-sharing applications are finding
" a need for alternative congestion-control when congestion limits the
" ability of TCP to ever fill the available bandwidth.

> This has lead ISPs to deploy ad-hoc solutions such as volume accounting,
> rate policing and deep packet inspection in an attempt to distribute
> capacity differently.

   Although I hate the concept of distributing "fairly", that is what
they claim to be attempting, and I think we should use their word.

> It is increasingly recognised that in today's internet this leads to
> issues from technical, business and regulatory viewpoints [ref problem
> statement, p2pi workshop].

   This sentence is a bit hard to read. Perhaps:
" 
" The consequences of such ISP practices are increasingly leading to
" calls for government regulations.

> The heart of the problem is that the internet lacks a system for
> accountability for causing congestion - accountability for end users
> to networks, networks to networks, and networks to end users.

   A bit sudden... Perhaps:
" 
" We believe these problems stem from a lack of a network-layer system
" for accountability -- among all parties -- for sending traffic which
" causes congestion.

> The key new metric proposed is that packets carry information about
> the rest-of-path congestion, so any node can see the congestion it
> causes others by sending or forwarding traffic.

   The reader stumbles a bit. Perhaps:
" 
" We propose a metric where IP packets carry information about the
" expected "rest-of-path" congestion, so that any forwarding point
" may know how much congestion it is likely to cause by forwarding
" that 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 congestion,
> they can discourage users from causing large volumes of congestion,
> and they can discourage other networks from allowing their users to
> cause congestion.  

   Good. (Magic is acceptable here. ;^)

> The main proposed item of work is to define the basic protocol that
> exposes the expected rest-of-path congestion in the IP header.
> The defined protocol should work with minimal changes to the existing
> network, in particular it should work with unmodified routers, and be
> transport-agnostic.

   Good. I'd break the paragraph here. (Transport-agnostic is our main
point -- we don't want it to get lost in the middle of a paragraph.)

> While the proposed WG will encourage experimentation with the new
> metric, it will not define in detail how exposed congestion should be
> used.

   A bit wimpy... Perhaps:
" 
" The proposed WG will not attempt to detail what management practices
" are appropriate for managing congestion, though we expect wide-ranging
" experimentation along those lines: our concern will be how well the
" protocol expresses expected and actual congestion.

> The proposed work items are:

   These need work, but not necessarily right now. In any case, I won't
address them in this email.

--
John Leslie <[email-masked]>

---

From: João Taveira Araújo <[email-masked]>
Date: Mon, 12 Oct 2009 17:33:09 +0100

> the latter like advanced technology.

I was wary of going into greater detail because I wasn't sure we want to 
convey the expected congestion / congestion experienced is the only 
means of achieving congestion exposure. Matt's proposal on checking for 
duplicate packets can reveal expected congestion for example. Likewise, 
the v6 version of re-ECN may potentially include a high-precision number 
in every packet (although this is up for grabs).

> "enables better resource allocation".

Simplifies in the sense networks don't have to infer congestion from 
loosely related metrics - such as traffic rate, volume or application 
type. Better might be more assertive though.

>    The other items are too broad for me to wordsmith at this time...

I don't think we should go into this much detail in the announcement 
itself. The reason I put these use cases in the first paragraph was to 
act as keywords and attract potential contributors from those areas. I 
do think this should be in the charter however.

>    "TCP congestion-control", I think.

Noted.

> " ability of TCP to ever fill the available bandwidth.

Half empty, half full. I was taking the opposite viewpoint because ISPs 
react adversely to heavy users taking too much, not too little. While 
your statement is correct (and is the driving force behind LEDBAT), it 
doesn't really tie in with the next sentence.

> they claim to be attempting, and I think we should use their word.

I wanted to avoid historically loaded terms. I'll leave this open to 
discussion to see if there is consensus on using "fairly".

>> statement, p2pi workshop]
>> *snip*
>>    A bit wimpy... Perhaps:
>> " 

All noted.

> address them in this email.

I just copied the work items from the draft charter, which is what I'll 
do in the final version, so any discussion relating to this list should 
be addressed on the charter thread. Thanks for the input, I'll be 
waiting a few more days for feedback before sending out another copy.

Joao.

---

From: <[email-masked]>
Date: Tue, 13 Oct 2009 11:15:09 +0100

A sprinkling of magic will enliven the BoF! Just a few bits in line...

Toby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of João Taveira Araújo
> Sent: 12 October 2009 17:33
> To: John Leslie
> Cc: [email-masked]
> Subject: Re: [re-ECN] ConEx BoF announcement
> 
> John Leslie wrote:

But it is magic! I agree we need to make sure people are able to believe we have a serious proposal here, not just a load of waffle and hot air.

> in every packet (although this is up for grabs).

I agree with João here - we want to avoid dictating the solution at this stage. But there is no harm in saying something like "one proposal has already been put forward that builds on ECN to add rest of path information into the IP header." (that will need some more work probably, but basically we say "yes this seems like magic but there is already at least one easy proposal to do this and more may be possible"

> type. Better might be more assertive though.

"allows greater freedom for resource allocation". Somewhere we need to highlight that this is just a way of adding information that can then be used to monitor how resources are being shared, thus freeing us from the constraints of e.g. TCP friendliness, flow fairness, etc.

> do think this should be in the charter however.

I think it would be nice to hint this is a powerful tool, but limit things to a short list initially with something like " This information may in turn be used for many purposes, including congestion policing, accountability and inter-domain SLAs. It also opens exciting possibilities for new approaches to QoS and traffic engineering." 
> doesn't really tie in with the next sentence.

I'll leave this to others to decide which way we put this emphasis. One thing though - currently no user has an incentive to use LEDBAT unless they are the primary cause of their own congestion (or have a stupid home router with a 2s queue). If we can shift the emphasis globally to congestion then suddenly ISPs will incentivise the use of LEDBAT, etc

> discussion to see if there is consensus on using "fairly".

"Fairly" probably should be avoided and not all ISPs claim that word - some just claim to be "limiting the impact of a minority of customers"

> waiting a few more days for feedback before sending out another copy.

Probably summarise the work items rather than list them - you can always include a link to the draft charter.

---

From: João Taveira Araújo <[email-masked]>
Date: Wed, 14 Oct 2009 22:15:07 +0100

Hi,

Here is the mash-up of the announcement taking into account list 
feedback. I've broken the first paragraph in two to make it less 
cluttered. It makes the intro sound less enticing, but at least it 
doesn't sound like magic now.

It's also a little longer than originally intended, but I'll let the BoF 
chairs put the finishing touches. This should be pretty much complete by 
tomorrow, so any feedback until then is welcome.

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 for resource allocation.

An existing proposal, builing on ECN to reveal "rest-of-path" information into the IP header, has already demonstrated how congestion exposure can free transport protocols from constraints such as TCP friendliness or flow fairness. We believe this information may in turn be used for many purposes, including congestion policing, accountability and inter-domain SLAs. It also opens 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.  TCP alone however 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 lead 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 [ref problem statement, p2pi].

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.

The main proposed item of work is to define the basic protocol that exposes the expected rest-of-path congestion in the IP header. The defined protocol should work with minimal changes to the existing network, in particular it should work with unmodified routers, and be transport-agnostic. 

Additional work items 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 will encourage experimentation but not deliberate on how congestion exposure should be used: our concern will be how flexibly the resulting protocol can adapt to differing needs at run-time, rather than dictating a particular outcome at design time.

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 14 Oct 2009 19:04:58 -0400

Great, thanks.

Also, with this (and listed separately on the BoF page), we probably 
want to highlight the relevant documents.

By "relevant", I mean valuable for understanding the work of this 
meeting (and the work already done) -- we can have a separate discussion 
about which ones an eventual WG would take up as work items, and 
whether/how they feature on the agenda.

As I see it, those documents are:

http://www.ietf.org/id/draft-moncaster-congestion-exposure-problem-00.txt
http://www.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp-08.txt
http://www.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp-motivation-01.txt

Any other suggestions, deflections?

Thanks,
Leslie.

João Taveira Araújo wrote:
> ------------------------------------------------------------------------
> 

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: <[email-masked]>
Date: Thu, 15 Oct 2009 09:20:39 +0100

I know Bob has done quite a number of publications and presentations in this field which can be found on his webpage:

http://www.bobbriscoe.net/projects/refb/ 

Not sure if we want to either reference the entire page or alternatively pick some key references?

BTW - quick update on the problem statement. After re-reading and having seen feedback from several co-authors and others on and off list it I realise it had started to slip into more of a "lets bash TFRC" document and was starting to blur the solution to a problem (lack of information) with a symptom of that problem (heavy-handed traffic control by ISPs). I am spending most of today working on this and hope to have a revised version out tonight (but no promises...).

Toby
____________________________________________________________________ 
Toby Moncaster, Senior Researcher, Network Infrastructure Practice
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170 

> Behalf Of Leslie Daigle
> Sent: 15 October 2009 00:05
> To: João Taveira Araújo
> Cc: [email-masked]

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 15 Oct 2009 13:18:24 +0200

Sounds great. 

Just the second paragraph doesn't really fit. Saying "... free transport 
protocols from constraints such as TCP friendliness or flow fairness." is not 
motivated at this point and feels misplaced. 
I would either put this paragraph before the last one or rewrite it to 
something like "... how congestion exposure can give an incentive to control 
one's impact on the network (in an endpoint) beside TCP congestion-control".

Mirja

---

From: <[email-masked]>
Date: Thu, 15 Oct 2009 14:34:33 +0100

Personally I've found bob's 7-page white paper the best for something that (I think) helps understand his work, and explains the overall approach of the protocol without getting into protocol details.
http://www.bobbriscoe.net/projects/refb/FairerFasterWP.pdf 

Best wishes,
Phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leslie Daigle
Sent: 15 October 2009 00:05
To: João Taveira Araújo
Cc: [email-masked]
Subject: Re: [re-ECN] ConEx BoF announcement

Great, thanks.

Thanks,
Leslie.

--