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

From: <[email-masked]>
Date: Fri, 16 Oct 2009 16:12:40 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: 16 October 2009 11:28
To: [email-masked]
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.

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 16 Oct 2009 23:02:09 -0400

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.

> re-ECN further towards the end. Also tries to tighten up the text a bit):
> 
>  
> 
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of [email-masked]
> *Sent:* 16 October 2009 11:28
> *To:* [email-masked]
> *Subject:* [re-ECN] ConEx BoF announcement text
> 
>  
> 
> Here’s a slightly revised version of the announcement text - thanks to 
> transport-agnostic, as I find ‘transport’ an ambiguous word & also think 
> beside TCP congestion-control. We believe this “congestion exposure” 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn

-- 

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

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 18 Oct 2009 16:38:16 +0100

Leslie,

Thanks for this.

Had you noticed that most of the linked refs are repeated a little 
further down the page (and one or two of the original links need to 
point to revved versions)?

Shall I tidy up, or would you rather?

Comments (minor) on the text itself next.

Bob

At 04:02 17/10/2009, Leslie Daigle wrote:

>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 
>>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, 
>>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:* [email-masked] [mailto:[email-masked]] 
>>*On Behalf Of [email-masked]
>>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.
>> 
>>
>>
>>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.
>>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 
>>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.
>>
>>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.
>>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Leslie Daigle <[email-masked]>
Date: Sun, 18 Oct 2009 12:55:22 -0400

Hi,

I'll confess to having been lazy about updating the rest of hte page :-) 
  I'll look at it again during the week, or feel free to tidy those up 
if you have a mo.  However, with respect to the duplication -- that was 
somewhat intentional.  My goal was to have a uniform chunk of text for 
the BoF, *including* references that can (and will) get circulated on 
mailing lists.

Thanks,
Leslie.

Bob Briscoe wrote:
>>> managed through the voluntary use of TCP congestion control.  
>>> 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).
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>>
>>>
>>> congestion exposure can give an incentive to control one's impact on 
>>> the network beside TCP congestion-control. We believe this 
>>> including congestion policing, accountability and inter-domain SLAs. 
>>> It may also open new approaches to QoS and traffic engineering.
>>>
>>> share capacity has been paramount to its success and has 
>>> 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).
>>>
>>> system for accountability -- among all parties -- for sending traffic 
>>> which causes congestion. We propose a metric where IP packets carry 
>>> 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.
>>>
>>> should work with minimal changes to the existing network, in 
>>> particular it should work with unmodified routers.
>>>
>>> detailing the motivations for congestion exposure, a threat analysis 
>>> of the subsequent protocol, providing feedback on experimental trials 
>>> 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: Bob Briscoe <[email-masked]>
Date: Sun, 18 Oct 2009 19:46:52 +0100

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 
>Internet. By revealing expected congestion in the IP header of every packet,

s/every packet/packets/

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

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

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

> allows greater freedom over how capacity is shared. Such 
> policing, accountability and inter-domain SLAs. It may also open 
> new approaches to QoS and traffic engineering.
>
>congestion control. However, TCP alone is unable to prevent 
>bandwidth intensive applications,

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

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

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

i/over time /

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

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

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

>This has led ISPs to deploy ad-hoc solutions such as volume 
>accounting, rate policing and deep packet inspection in an attempt 
>to distribute capacity differently. The consequences of such 
>layer (see for example, the problem statement I-D (ref below) and RFC5594).
>
>traffic which causes congestion.

s/sending/forwarding/

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

>We propose a metric where IP packets carry information about the 
>expected rest-of-path congestion, so that any network node may 
>estimate how much congestion it is likely to cause by forwarding 
>traffic. A network operator can then count the volume of congestion 
>about to be caused by an aggregate of traffic as easily as it can 
>count the volume of bytes entering its network today. Once ISPs can 
>see rest-of-path congestion, they can actively discourage

d/actively /

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

>freed from rate restrictions where their traffic causes little congestion.

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

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

>in particular it should work with unmodified routers.

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

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

>rest-of-path congestion information in every IP header

s/every IP header/IP headers/

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

s/that protocol/its chosen congestion exposure protocol/

>as its main work item.

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

>Additional work items could include detailing the motivations for 
>congestion exposure, a threat analysis of the subsequent protocol, 
>providing feedback on experimental trials and describing deployment 
>considerations.

s/providing feedback on/reporting on/

>Importantly, the proposed WG would encourage experimentation but not 
>deliberate on how congestion exposure should be used: our concern 
>would be how flexibly the resulting protocol can support differing 
>needs at run-time, rather than dictating a particular usage at design time.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 18 Oct 2009 19:55:00 +0100

Leslie,

OK, in that case, I'd rather remove the duplicate refs from lower down.
I'll do that now.

I'll add a brief word on what each reference is (using the words 
deleted from the end).

I'll also add a ref to the page for subscribing to the list, not just 
sending to it.

Bob

At 17:55 18/10/2009, Leslie Daigle wrote:

>Hi,
>
>I'll confess to having been lazy about updating the rest of hte page 
>:-)  I'll look at it again during the week, or feel free to tidy 
>those up if you have a mo.  However, with respect to the duplication 
>-- that was somewhat intentional.  My goal was to have a uniform 
>chunk of text for the BoF, *including* references that can (and 
>will) get circulated on mailing lists.
>
>Thanks,
>Leslie.
>
>Bob Briscoe wrote:
>>Leslie,
>>Thanks for this.
>>>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):
>>>>
>>>>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.
>>>>
>>>>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 
>>>>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 
>>>>include detailing the motivations for congestion exposure, a 
>>>>threat analysis of the protocol, providing feedback on 
>>>>Here's a slightly revised version of the announcement text - 
>>>>thanks to Joao and everyone who worked on it.
>>>>
>>>>traditionally been managed through the voluntary use of TCP congestion control.
>>>>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).
>>>>
>>>>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

---

From: <[email-masked]>
Date: Mon, 19 Oct 2009 14:07:49 +0100

Bob
Some (personal) comments in-line
Best wishes,
phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bob Briscoe
Sent: 18 October 2009 19:47
To: Leslie Daigle
Cc: [email-masked]
Subject: Re: [re-ECN] FW: ConEx BoF announcement text

Leslie,

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

========================================================================
====

s/every packet/packets/

[phil] agree with your change

[phil] personally I don't find your version any more or less clear than
the current text. maybe a 3rd version is needed!

i/over time /

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

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

[phil] ok

RFC5594).

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"

d/actively /

[phil] ok

congestion.

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

[phil] I have no strong preference where this text appears

>If supported, an eventual WG would focus on the development of that
protocol

[phil] ok

Bob

---

From: <[email-masked]>
Date: Mon, 19 Oct 2009 16:16:16 +0100

One comment inline

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: 19 October 2009 14:08
> To: Briscoe,RJ,Bob,XVR9 BRISCORJ R; [email-masked]
> Cc: [email-masked]
=======================================================================
> =

So let's condense it to its essence "TCP alone is unable to prevent some
users from having a disproportionately large impact on the experience of
other users."
 {{{Reasoning: TCP is a protocol, what matters here is the people and
the impact they have on each other. ConEx provides a way of measuring a
relevant metric for this...}}}

> >>to re-ECN further towards the end. Also tries to tighten up the text
> a
> bit):
> >>
>>---------------------------------------------------------------------
> -
> --

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 19 Oct 2009 21:55:10 -0400

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):

> pasted it from the wiki below, and added my comments.

Done

> s/bandwidth intensive applications/applications transferring high 

Not done -- agree with Phil.

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

Done.

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

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

> easiest solution is to say "sending or forwarding"

Changed to sending or forwarding.

>> see rest-of-path congestion, they can actively discourage

Done.

> [[[Your original had wording around this idea that has got lost in 

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.

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

> s/every IP header/IP headers/

Done.

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

> s/providing feedback on/reporting on/

Done.

Thanks,
Leslie.

--

---

From: <[email-masked]>
Date: Tue, 20 Oct 2009 10:17:01 +0100

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

> Behalf Of Leslie Daigle
> Sent: 20 October 2009 02:55
> To: Briscoe,RJ,Bob,XVR9 BRISCORJ R
> Cc: [email-masked]
> Behalf
> >> Internet. By revealing expected congestion in the IP header of
every
> > packet,
to
> >> regulations and stifling innovation at the transport and
application
> >> meaningfully differentiate between the qualities of services
offered
> >> Importantly, the proposed WG would encourage experimentation but
not
> >> needs at run-time, rather than dictating a particular usage at
> design
> > time.
> >
> 
> 
> Thanks,
> Leslie.
> 
> >
> >
> > Bob
> >
> >>> to re-ECN further towards the end. Also tries to tighten up the
> text a
> > bit):
packet,
> >>> include detailing the motivations for congestion exposure, a
threat
> >>> Here's a slightly revised version of the announcement text -
thanks
> >>> applications, such as peer-to-peer or streaming video, from
causing
> >>> operator can then count the volume of congestion about to be
caused
> >>> If supported, an eventual WG would focus on the development of
that
> >>> include detailing the motivations for congestion exposure, a
threat

---

From: [email-masked]
Date: Tue, 20 Oct 2009 11:01:26 +0000

suggest changing the word "user" to "application"

--bill

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 20 Oct 2009 17:31:09 -0400

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.

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.

--

---

From: Richard Bennett <[email-masked]>
Date: Tue, 20 Oct 2009 15:09:11 -0700

Per the original design of the Internet protocols, the responsibility 
for managing congestion fell on IP, not on TCP. The function was moved 
to TCP by Jacobson because the IP/ICMP method was unreliable for a 
number of reasons. The TCP solution was meant to be a short-term fix 
that would be replaced by a longer-term, better placed congestion 
control function. The TCP solution was several shortcomings:

1. Leads to Global Synchronization.
2. Takes a long time to react to congestion events.
3. Fails to keep the pipe saturated.
4. Isn't fair on a per-user basis.
5. Wastes resources by discarding packets at some random point in their 
path.
6. Treats all applications the same regardless of their requirements.
7. Doesn't do diddly for UDP.

Congestion exposure enables the development of systems of congestion 
management that are more effective, faster, more fair, and more 
resource-efficient than TCP-based solutions can be.

RB

Leslie Daigle wrote:
> I'm concerned that rephrasing is getting a bit circular in logic -- 
> "we need congestion exposure because TCP can't do adequate congestion 
> 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.
>
>
>

-- 
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC

---

From: Richard Bennett <[email-masked]>
Date: Tue, 20 Oct 2009 15:22:37 -0700

Adding on a bit, Congestion Exposure is wiser than TCP-based congestion 
management from a control-theoretic perspective by placing the control 
closer to the resource being controlled, and also frees the Internet 
from architecturally inelegant, unnecessary and counter-productive 
dependence on one particular transport protocol; restores proper 
layering, IOW.

RB

Richard Bennett wrote:
> 5. Wastes resources by discarding packets at some random point in 
> their path.
>> Generally, to the whole list -- let's step back and look at the set 
>> of sentences.
>>
>>
>> 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.
>>
>>
>>
>>
>> applications?  And, what is the objective description of the impact 
>> of TCP congestion control on this different traffic type?
>>
>> that these applications are wrong or evil, TCP congestion control 
>> just isn't applicable.
>>
>> How can we capture that?
>>
>> Leslie.
>>
>>
>>

---

From: <[email-masked]>
Date: Wed, 21 Oct 2009 12:43:11 +0100

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

> From: Leslie Daigle [mailto:[email-masked]]
> Sent: 20 October 2009 22:31
> To: Moncaster,T,Toby,DEE1 R
> Cc: Briscoe,RJ,Bob,XVR9 BRISCORJ R; [email-masked]
> >> it easier for all of us to track what is (and is not) changing in
> the
> >> text.
> >>
> >>> I have a few suggestions that seem like nits, but they are
> important
> >> (to
> >>> me).
> >>>
> wording
> references
> (ref
> for
> (ref
> viability

---

From: <[email-masked]>
Date: Wed, 21 Oct 2009 13:50:10 +0100

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?

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

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.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 21 October 2009 12:43
To: [email-masked]
Cc: [email-masked]
Subject: Re: [re-ECN] FW: ConEx BoF announcement text

Toby

---

From: <[email-masked]>
Date: Wed, 21 Oct 2009 14:05:32 +0100

Inline...

> From: Eardley,PL,Philip,DEE1 R
> Sent: 21 October 2009 13:50
> To: Moncaster,T,Toby,DEE1 R; [email-masked]
> Cc: [email-masked]
> Subject: RE: [re-ECN] FW: ConEx BoF announcement text
> 
> 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)

> << The Internet is, in essence, about pooling resources. The ability to
> many other users. This has led ISPs to deploy ad-hoc solutions such as
> practices are increasingly leading to calls for government regulations
> and stifling innovation at the transport and application layer (see for

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

> Behalf Of [email-masked]
> 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
> 
> "we
> of
> traditionally
> control
> > > downloads, stuttering video, unresponsive websites, etc. There is
> no
> > one
> > >>> For example, Sally Floyd was much less concerned about re-ECN
> once
> > I
> > >>> Anyway, on practicality grounds, an ISP can't force all IP
> traffic
> > > to
> > >>> [phil] personally I don't find your version any more or less
> clear
> > >> than
> > >> Done.  As a bit of a gripe:  "user experience" is not
> quantifiable.
> > > It
> > >>> [phil] maybe this depends whether you think forwarding is a
> subset
> > > or
> > >> No change made -- I think positing TCP-friendliness could be
> relaxed
> > > is
> > >> boundaries that exists.  Having said that, I don't care where it
> is,
> > >> and
> > >> "The chosen protocol will need to be deployable with minimal
> changes
> > > to
> > >>>>> cause, and more meaningfully differentiate between the
> qualities
> > > of
> > >>>> ----------------------------------------------------------------
> --
> > -
> > >>>> "Reality:
> > >>>>      Yours to discover."
> > >>>>                                 -- ThinkingCat
> > >>>> Leslie Daigle
> > >>>> [email-masked]
> > >>>> ----------------------------------------------------------------
> --
> > -

---

From: Kwok Ho Chan <[email-masked]>
Date: Wed, 21 Oct 2009 09:46:33 -0400

Hi Phil:
I have the following suggested change to the paragraph you indicated:

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

To:
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 is a transport layer mechanism that applies 
only to the Internet traffic using the TCP transport.  With the
advent of new applications not utilizing the TCP 
Transport Layer, the ability for the Internet to share capacity
as designed is questioned.  This has led ISPs to deploy ad-doc solutions ...

Regards!
-- Kwok --

At 08:50 AM 10/21/2009, [email-masked] wrote:
>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?
>
><< 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).
> >>
>
>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....
>
>
>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.
>
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of [email-masked]
>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...
>

---

From: João Taveira Araújo <[email-masked]>
Date: Wed, 21 Oct 2009 17:13:49 +0100

Hi,

Kwok Ho Chan wrote:
> However,
> TCP is a transport layer mechanism that applies only to the Internet 
> traffic using the TCP transport.  With the
> advent of new applications not utilizing the TCP Transport Layer, the 
> ability for the Internet to share capacity

Unfortunately this doesn't refer to the cases where even the use of TCP 
fails to address the problem. While other transport protocols which do 
not respond to congestion do hinder efforts for better resource 
allocation, the core issue is that even if every flow abides to 
TCP-friendliness the outcome may still favour certain (aggressive) 
behaviour. The elephant in the room here is the concept of flow 
fairness. TCP alone is unable to prevent traffic-intensive applications 
from spawning multiple flows in a bid to speed up transfers for example.

Cheers,
Joao.

>> 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?
>>
>> << The Internet is, in essence, about pooling resources. The ability 
>> 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 
>> 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....
>>
>>
>> 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:-
>> example, applications could transmit faster where their traffic 
>> causes little congestion.
>>
>>
>> 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
>>

---

From: John Leslie <[email-masked]>
Date: Wed, 21 Oct 2009 12:37:32 -0400

[email-masked] <[email-masked]> wrote:
> 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.

   Yes!

> Such applications are able to cause enough congestion over time to
> severely impair the quality of experience of other users.

   True, but not quite right. Perhaps:
" 
" Such applications need to be a bit more aggressive than TCP under
" some circumstances even if they are less aggressive on average. ISPs
" are unable to tell whether such applications are, on average, more
" or less aggressive than standard TCP congestion-control.

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

   Yes.

> The consequences of such practices are increasing calls for government
> regulation and stifling innovation at the transport and application
> RFC5594)."

   The reader stumbles a bit over this. Perhaps:
" 
" Since such practices cannot distinguish whether the policing actually
" matches the problem, they tend to stifle innovation at the transport
" and application layers. Also, such practices often appear to be aimed
" at stifling competitors to those ISPs, leading to increasing calls for
" government regulation.

--
John Leslie <[email-masked]>

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 21 Oct 2009 23:01:40 -0400

I think this is getting close...

>> peer-to-peer or streaming video that break some of its fundamental

It would be really nice to articulate something about those violated 
design assumptions.  Detail left to the problem draft, if anywhere. 
But, perhaps:

"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.  This is 
does not generally work for peer-to-peer or streaming video applications."

> " or less aggressive than standard TCP congestion-control.

I think it's not just "ISPs" -- it's all network operators, right?  so, 
running with the "can't tell which applications are which" idea, maybe:

"In order to avoid congestion from such applications, more aggressive 
control is required in some circumstances than is provided by standard 
TCP congestion control.  Networks are currently unable to accurately 
detect these applications' traffic or the circumstances in which 
additional control should be applied.  "

Yes.

> " at stifling competitors to those ISPs, leading to increasing calls for

I think the rewrite loses the fact that government regulation could 
equally cause stifling of innovation.

Leslie.

--

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 22 Oct 2009 19:07:30 +0100

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):
>
>
>>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.
>>]]]
>>
>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 :-) ).
>
>>>application layer (see for example, the problem statement I-D (ref below) and
>>RFC5594).
>>>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
>>>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./
>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.
>
>>
>>d/Any such protocol should work with minimal changes to the 
>>existing network, in particular it should work with unmodified routers./
>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
>>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.
>
>>
>>>providing feedback on experimental trials and describing 
>>>deployment considerations.
>>>differing needs at run-time, rather than dictating a particular usage at design
>>time.
>
>
>Thanks,
>Leslie.
>
>>
>>Bob
>>>>offered from potential connectivity partners. Meanwhile end-hosts may be freed

---

From: Fred Baker <[email-masked]>
Date: Thu, 22 Oct 2009 11:36:38 -0700

I'll argue something slightly different. It comes to the same  
endpoint, but through a different observation. Some of us, you Bob  
especially, are very familiar with this; others are perhaps less so.  
Bear with me.

Jain's 1994 patent on congestion control defines two terms: the  
"cliff" and the "knee" of a throughput curve.

            |
        T   |      availabile capacity
        h   | ---------------------------------------
        r   |       +---+
        u   |  knee/     \cliff
        p   |     /       \
        u   |    /         \
        t   |   /           \
            |  /             \
            | /               \
            |/                 ----------------
            -----------------------------------------
                      Window  --->

As the TCP/SCTP window increases from zero to some value, throughput  
also increases. That stops when the available capacity has been  
consumed; at that point, even if the window grows, throughput does  
not. What increases instead is RTT, because a queue grows. If window  
continues to increase, at some point the queue starts dropping  
traffic, and throughput degrades. By definition, the window at the  
"knee" is smaller than the window at the "cliff", but throughput is  
the same.

Common TCP congestion control algorithms such as Reno and Cubic tune  
to the cliff. That has the upside of maximizing throughput; it has the  
downside that it is abusive to other applications such as voice/video  
(increased and variable RTT, and induces loss), and to other TCP  
sessions. #include <discussion of bittorent and why other users are  
negatively impacted by it>

Other TCP congestion control algorithms based on ECN, CalTech FAST,  
etc, try to tune to the knee. This gets them exactly the same  
throughput including support of very high rate applications but with a  
smaller window value and therefore lower queue depth and lower  
probability of loss - both for themselves and their competitors. It  
does so without negatively, or at least AS negatively, impacting  
applications they compete with beyond seeking to share the available  
capacity with them.

On Oct 22, 2009, at 11:07 AM, Bob Briscoe wrote:

> Leslie,
>
> I accept all the changes you've made except one, which we really  
> must stop saying.
>
> 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.
>
> [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  
> 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
> 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.
>
>> makes it easier for all of us to track what is (and is not)  
>> changing in the text.
>>
>>> important (to
>>> [[[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.
>>> some transports like TCP and not others like DNS/UDP. Obviously,  
>>> if an ISP uses congestion exposure in the future to limit heavy  
>>>> accounting, rate policing and deep packet inspection in an  
>>>> attempt to distribute capacity differently. The consequences of  
>>>> (ref below) and
>>>> 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
>>>> little
>>> i/In this environment the self-imposed constraint of TCP- 
>>> friendliness could be relaxed, allowing a richer variety of  
>> relaxed is probably overreaching (happy to be educated otherwise),  
>> and largely think the rest is covered in the "Meanwhile" sentence.
>>
>>>
>>>> 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.
>> is, and am happy to migrate it closer to the proposal text.
>>
>>>
>> changes to the existing Internet, preferably working with  
>> unmodified routers."
>>
>>>> congestion exposure, a threat analysis of the subsequent  
>>>> protocol, providing feedback on experimental trials and  
>>>> describing deployment considerations.
>>>> usage at design
>>>>> The Internet is, in essence, about pooling and sharing  
>>>>> resources. This has been paramount to its success and has  
>>>>> bandwidth intensive applications, such as peer-to-peer or  
>>>>> streaming video,
>>>>> 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  
>>>>> 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  
>>>>> 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  
>>>>> word & also think the substantive point is already made by  
>>>>> saying the congestion is revealed in the IP header.
>>>>>
>>>>> 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  
>>>>> 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.
>>>>> 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  
>>>>> 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.
>>>>>
>>>>> 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.

---

From: "Ilpo Järvinen" <[email-masked]>
Date: Thu, 22 Oct 2009 22:36:41 +0300 (EEST)

On Thu, 22 Oct 2009, Fred Baker wrote:

> I'll argue something slightly different. It comes to the same endpoint, but
> through a different observation. Some of us, you Bob especially, are very
> familiar with this; others are perhaps less so. Bear with me.
> 
> Jain's 1994 patent on congestion control defines two terms: the "cliff" and
> the "knee" of a throughput curve.
> 
>           |
>       T   |      availabile capacity
>           |/               \
> As the TCP/SCTP window increases from zero to some value, throughput also
> increases. That stops when the available capacity has been consumed; at that
> point, even if the window grows, throughput does not. What increases instead
> is RTT, because a queue grows.

Up to this point I agree with this paragraph...

> If window continues to increase, at some point the queue starts dropping 
> traffic, and throughput degrades.

...However, this is not a true claim. As long as no unnecessary work is 
not done at any bottleneck (and we don't have a shared resource such as 
a wireless channel), thoughput does _not_ degrade (at all!), even though 
many keep asserting that without much of a thought nowadays. Of course 
non-infinitely long flows would introduce some anomalities to calculations 
through which one could use to show that this claim is "true" but I think 
that's hardly what people usually mean when they make that claim that 
dropping implies throughput degradation.

Somewhat related, for some reason there's a very common misconcept that 
drops imply poor performance. That is often stated as a fact without 
looking deeper into what really was the cause for sub-optimal 
performance, often that turns out to be something else when looked 
closely enough. I'd say that very often losses were, in fact, innocent.
Quite often the blame would fall on constant factor MD (if one is honest 
enough to admit).

Btw, your graph is not accurate (wrt. Jain), he's drawing a much sharper 
drop than you do at his "cliff" (so with ascii you'd have to use | at 
first to match him). I've some doubts about validity of that sharp 
angle too, so I find your graph is much more sensible (that is, as long as 
the resource is shared).

> By definition, the window at the "knee" is smaller than the window at 
> the "cliff", but throughput is the same.
> 
> Common TCP congestion control algorithms such as Reno and Cubic tune to the
> cliff. That has the upside of maximizing throughput; it has the downside that
> it is abusive to other applications such as voice/video (increased and
> variable RTT, and induces loss), and to other TCP sessions. #include
> <discussion of bittorent and why other users are negatively impacted by it>

I think Bob doesn't agree with you here, he isn't saying that congestion 
is something bad but something nearly opposite. Bob's own words:

"It would contradict this to say congestion is a problem - it's not - it's 
healthy and natural in a data network."

...It's just that if you keep doing that too much (beyond the congestion 
volume allocated for you), you would "suffer (if I've understood him 
right). ...So it has very little to do with operating in the "cliff" or 
"knee" in short timescales (unless of course you've already ran out of 
your quota).

> Other TCP congestion control algorithms based on ECN, CalTech FAST, etc, try
> to tune to the knee. This gets them exactly the same throughput including
> support of very high rate applications but with a smaller window value and
> therefore lower queue depth and lower probability of loss - both for
> themselves and their competitors. It does so without negatively, or at least
> AS negatively, impacting applications they compete with beyond seeking to
> share the available capacity with them.

I certainly agree with you here that low queuing delay is a desirable 
property too. ...However, I don't see how e.g., ECN alone could achieve 
low queue delay and high throughput at the same time, you'd need something 
more than that (mainly to remove the 0.5 factored MD). And after removing 
that, we'd get something close to what Matt Mathis is suggesting and that 
then does not anymore depend on ECN to work (though I think one could 
certainly avoid lots of loss recovering by signalling in early with 
ECN).

-- 
 i.

---

From: Fred Baker <[email-masked]>
Date: Thu, 22 Oct 2009 13:38:37 -0700

well, we disagree on some points. I don't know that perfect agreement  
is necessary, and certainly not on this thread. That said...

Regarding behavior beyond the cliff, it might be instructive to take  
the most extreme possible case - a dumbbell network and a really  
obnoxious file transfer algorithm.

          +-+ 10*N   +-+ 10*N  +-+   N  +-+ 10*N  +-+
          |A|--------|B|-------|C|------|D|-------|E|
          +-+        +-+       +-+      +-+       +-+
                 10*N |         |10*N
                    +--+      +--+
                    | F|      | G|
                    +--+      +--+

Presume that the capacity from C to D is N, and all other capacities  
are 10*N. Presume that some application at A wants to send something  
really big to a peer at E, and some other application at F wants to  
send something else to a peer at G.

Presume also that the way file transfers work is that the sender puts  
appropriate headers on all of the indicated packets, queues them up to  
its link layer chip, and spews them as fast as it can. If it's a 100  
gigabyte file, it queues up 100 gigabytes and watches it heat the  
"wires". The peer receives what it receives and tells the sender what  
it didn't. The sender now repeats the exercise with anything his peer  
didn't receive.

BTW, that is in fact how a file transfer done in a certain research  
environment on very noisy lines is proposed to work. I didn't just  
dream that up.

Obviously, links A-B, B-C, F-B, and C-D will be fully utilized. Since  
B-C has less (half) capacity than A-B + F-B, each of those flows will  
drop about half of its traffic. The transfer rate F-G should be around  
5*N. C-D will also drop 80% of the remaining traffic, resulting in an  
arrival rate at E of N. A will go through at least ten iterations of  
its transfer, and F at least two.

The first down side is that while A-B and F-B are fully utilized, most  
of that capacity is wasted. This impacts F's ability to deliver  
traffic to G; it should have achieved 90% throughput rate (the rate C- 
G less the rate C-D), and in fact achieved 50% or less. With the right  
mechanism (ack clocking comes to mind, and there are other  
approaches), the capacity used by the file transfer on A-B is only 10%  
used and there is at most a 10% impact on the file transfer F-G.

The second down-side is that the traffic arriving at G and E will be  
scattered all through the respective files, meaning that they have to  
store the bits and pieces and do a fair bit of searching and sorting  
to determine what they have not yet received and to reconstitute the  
file. This is a waste both of memory and CPU resources.

Voila, we come back pretty quickly to wanting the transmission rate of  
A to approximate the reception rate at E and the transmission rate at  
F to approximate the reception rate at G, and wanting the window to  
not be excessively large. An excessively large window wastes bandwidth  
before the bottleneck and potentially creates unnecessary bottlenecks,  
impacts other file transfers, imposes a memory/algorithm burden on the  
receiver, and for all of those costs accomplishes nothing that a  
smaller window would not have accomplished better.

A window that is too large is a bad thing, and the congestion it  
causes is a bad thing. Not that the presence of congestion is bad - it  
is, as Bob says, a natural side effect of what happens. But congestion  
that is poorly managed by the endpoint and/or the network is a very  
bad thing. re-ecn does in fact try to give the sender an incentive to  
approximate the knee (the smallest window that achieves the potential  
throughput rate), and increasing it to or beyond the cliff by  
definition doesn't increase it's rate materially beyond that point.

On Oct 22, 2009, at 12:36 PM, Ilpo Järvinen wrote:

>> endpoint, but
>> etc, try

---

From: "Ilpo Järvinen" <[email-masked]>
Date: Fri, 23 Oct 2009 01:30:01 +0300 (EEST)

On Thu, 22 Oct 2009, Fred Baker wrote:

> well, we disagree on some points.

I guess we agree quite much yes. However, what I'm pretty much still 
lacking the connection you made between Cubic/Reno and throughput 
reduction because of "the cliff". I oppose such an universal statement you 
made earlier about the cliff being there if we keep pushing the network. 
E.g., you put earlier Cubic among the "bad ones" who push the network, but 
now your scenario below doesn't have anything that even remotely resembles 
Cubic/Reno but something totally unresponsive (I'm assuming SACK based 
recovery is there with this defination of Reno, and that router buffers 
are large enough to accommodate MD-madness "recovery"). ...That's the 
connection I want to fully tear down. Don't first put Cubic or Reno into 
bads than show an example with something completely different, it isn't 
very fair to blame something from others faults like that and justify 
their "badness" that way. This is very important because this 
mis-connection is there in many minds that when enough congestion, 
throughput automatically dramatically drops (like in the Jain's graph). As 
a result, we hear these "congestion is the problem", and "more aggressive 
means more congestion" type of an attitude. Just to make sure, I didn't 
mean to say here that I'd think that Cubic/Reno is something perfect 
either.

...The rest is just some comments to your rather intimidated scenario :-).

> I don't know that perfect agreement is necessary, and certainly not on 
> this thread. That said...
> 
> Regarding behavior beyond the cliff, it might be instructive to take the most
> extreme possible case - a dumbbell network and a really obnoxious file
> transfer algorithm.
> 
> Presume that the capacity from C to D is N, and all other capacities are 10*N.
> Presume that some application at A wants to send something really big to a
> peer at E, and some other application at F wants to send something else to a
> peer at G.
> 
> appropriate headers on all of the indicated packets, queues them up to its
> link layer chip, and spews them as fast as it can. If it's a 100 gigabyte
> file, it queues up 100 gigabytes and watches it heat the "wires". The peer
> receives what it receives and tells the sender what it didn't. The sender now
> repeats the exercise with anything his peer didn't receive.
>
> environment on very noisy lines is proposed to work. I didn't just dream that
> up.
> 
> Obviously, links A-B, B-C, F-B, and C-D will be fully utilized. Since B-C has
> less (half) capacity than A-B + F-B, each of those flows will drop about half
> of its traffic. The transfer rate F-G should be around 5*N. C-D will also drop
> 80% of the remaining traffic, resulting in an arrival rate at E of N. A will
> go through at least ten iterations of its transfer, and F at least two.
>
> of that capacity is wasted.

Yes, that's the nature of unresponsiveness you added by yourself, and now 
you say that it is a down side?!? ...Nobody (including the network) can 
prevent an application from doing stupid things like wasting the resources 
of the first link :-). I understand though that you could construct a more 
complex topology where it wouldn't be the first link.

Instead of tackling that possibility, I take another extreme example to 
stress the point of mine: An application could cause the very same 
symptoms as were with the classical congestion collapse (as per Nagle) 
just by keeping resending just the very same segment even though it made 
through (and ACK was received), only multiple copies are then in the 
network and the throughput of that particular flow will be dramatically 
affected. But it's just plain stupid behavior which no network can prevent 
you from doing. Of course nobody else would have to be part of that 
experiment and they can operate with good throughputs. In a thought 
experiment we can put a TCP implementation with SACK and lots of receiver 
window into the age of Nagle and prove that it keeps operating with very 
good throughput regardless of what the stupid senders do as long as the 
transfer isn't unlucky to run of data to send while recovering.

...Secondly, I don't find this non-optimal use of excess capacity to be 
the reason why one would need/want Re-ECN.

Another stupidity of the application/protocol in this example is the way 
of feedback which exaggerates anomalities nearby the end of a transfer.

> This impacts F's ability to deliver traffic to G; it
> should have achieved 90% throughput rate (the rate C-G less the rate C-D), and
> in fact achieved 50% or less. With the right mechanism (ack clocking comes to
> mind, and there are other approaches), the capacity used by the file transfer
> on A-B is only 10% used and there is at most a 10% impact on the file transfer
> F-G.

...Right, would there be responsiveness, all changes. And I guess we then 
pretty much agree.

> store the bits and pieces and do a fair bit of searching and sorting to 
> determine what they have not yet received and to reconstitute the file. 
> This is a waste both of memory and CPU resources.

This has nothing to do with the throughput reduction anymore, don't you 
think? Also, to me these seem "extras" again are because of stupid 
behavior introduced by you rather than anything very close to what I was 
arguing against.

But in general I agree with you that loss recovery even without any 
throughput loss introduces these space constraints (though in a lot less 
severe way than in your extreme example) and one would want to avoid that 
if at all possible. But IMHO that again has rather little to do with "the 
cliff" and the throughput reduction (that supposedly happens because of 
it).

> Voila, we come back pretty quickly to wanting the transmission rate of A to
> approximate the reception rate at E and the transmission rate at F to
> approximate the reception rate at G, and wanting the window to not be
> excessively large. An excessively large window wastes bandwidth before the
> bottleneck and potentially creates unnecessary bottlenecks, impacts 
> other file transfers, imposes a memory/algorithm burden on the receiver, 
> and for all of those costs accomplishes nothing that a smaller window 
> would not have accomplished better.

Agreed. ...Noted though that you have for some reason cleverly milded 
the "reduces throughput" into "_potentially_ creates unnecessary 
bottlenecks" (emphasis mine) here which I can certainly agree much
more ;-).

...In fact, I'd even not choke because of your example here, if given in 
less extreme form, as we have CBR type of non-responsiveness present too 
for real, and thus dead packets wasting capacity (without ECN) and so on.

> A window that is too large is a bad thing, and the congestion it causes is a
> bad thing. Not that the presence of congestion is bad - it is, as Bob says, a
> natural side effect of what happens. But congestion that is poorly managed by
> the endpoint and/or the network is a very bad thing. re-ecn does in fact try
> to give the sender an incentive to approximate the knee (the smallest window
> that achieves the potential throughput rate), and increasing it to or beyond
> the cliff by definition doesn't increase it's rate materially beyond that
> point.

Agreed. Like you pointed out earlier, there's no increase in throughput 
beyond that point not matter what trick one tries to play and I agree.
My point was just to say that with responsive transfers there isn't such 
magic cliff (always), but the throughput would just keep that constant 
line even if drops start to occur. And especially mentioning Cubic/Reno, 
which are responsive, in this context of "cliff" seemed very misleading.

--
 i.

-- 
 i.

---

From: Fred Baker <[email-masked]>
Date: Thu, 22 Oct 2009 15:51:31 -0700

:-)

You started out by telling me that arbitrarily increasing the window  
doesn't hurt anything - you quoted Bob saying that congestion isn't a  
problem. I demonstrated that congestion out of control is a problem.  
Then you complained that I didn't demonstrate that Cubic/Reno is a  
problem. OK, let's talk about Cubic/Reno, and why Bittorrent has a  
working group in the IETF (ledbat) about how to reduce the impact on  
ISPs and their customers when they run seven Cubic/Reno TCPs in  
parallel.

Actually, could I get you to read the ledbat charter? http://www.ietf.org/dyn/wg/charter/ledbat-charter.html

On Oct 22, 2009, at 3:30 PM, Ilpo Järvinen wrote:

>> dream that
>> causes is a
>>>> increases. That stops when the available capacity has been  
>>>> consumed; at
>>>> that
>>>> point, even if the window grows, throughput does not. What  
>>>> increases
>>>> instead
>>>> cliff. That has the upside of maximizing throughput; it has the  
>>>> downside
>>>> that
>>>> Other TCP congestion control algorithms based on ECN, CalTech  
>>>> FAST, etc,
>>>> try
>>>> themselves and their competitors. It does so without negatively,  
>>>> or at
>>>> least

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 23 Oct 2009 22:59:02 -0400

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:>
</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.  This is 
does not generally work for peer-to-peer or streaming video 
applications.  In order to avoid congestion from such applications, more 
aggressive control is required in some circumstances than is provided by 
standard TCP congestion control.  Networks are currently unable to 
accurately detect these applications' traffic or the circumstances in 
which additional control should be applied. 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>

Though I'm suspecting that some instances of "congestion" should be 
replaced by "performance".

Leslie.

Bob Briscoe wrote:
> And implying intensive bandwidth usage needs to be prevented is rubbish 
> marketing for the idea behind ConEx, given it *enables* higher bandwidth 
> apps.
> 
> 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 
> [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>]
> 
> 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
> 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.
> 
>>>> 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 
>> 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 :-) ).
>>
>> is probably overreaching (happy to be educated otherwise), and largely 
>>>>> applications, such as peer-to-peer or streaming video,

--

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 24 Oct 2009 17:06:22 +0100

Fred, Ilpo,

Fred's right that out of control congestion can 
be *a* problem. Perhaps Ilpo is trying to say 
that "out of control congestion is not *the* problem"...

There's been some discussion about how to explain 
to the average IETFer in the BoF what ConEx is 
trying to do. Lars in particular wants us to 
avoid confusing everyone with all the possible 
things ConEx might do; but instead to focus on 
the most important single thing (*the* ConEx problem).

We can't say the problem is how to expose 
congestion - no-one would understand why. There's 
some consensus around focusing on the problem of 
"accountability for contributing to congestion" or "capacity sharing".

=== Problem A: Congestion Collapse ===
One day we could get congestion out of control on 
the Internet if the traffic mix changes, and 
there's still nothign to stop it. If the traffic 
mix was moving towards danger of collapse, it 
would be easy to deploy some form of 
network-based congestion policing if we already 
had ConEx on the Internet, thus averting collapse.

=== Problem B: Capacity Sharing ===
Most IETFers know there's a present palpable 
problem around capacity sharing. Some will have 
different favoured solutions (e.g. ISPs deploy 
more capacity to make the problem go away), but 
most agree it's a present problem.

I think we could all 3 agree on the following table:

Problem A (collapse)    B (poor sharing)
_______________________________________________________
Reno/Cubic      :)              :(
LEDBAT          :)              :|
ConEx           :)              :)

We could make the future danger of collapse (A) 
an argument for a ConEx w-g, but I suspect we'll 
get told "TCP's still prevalent; No collapse 
problem imminent; No need to listen to these 
doom-mongers." It would be better to make sharing 
(B) the primary problem that needs a w-g, 
then  near the end of the BoF, highlight that it 
would also prevent collapse (A).

_____________
Incidentally, why do I put a half-smiley for 
LEDBAT? It's the right thing to do first, but 
there are many arguments why ConEx will probably be needed too:
1) Heavy/background apps don't have to use LEDBAT
2) ISPs don't have a way to encourage LEDBAT
    (ISPs that limit volume will limit LEDBAT the same as TCP or UDP volume)
3) LEDBAT is designed primarily to handle self-congestion in slow links
   (it aims at 25ms queue delay, which overflows 
most fast shared link's queues)
4) When LEDBAT detects drop it stops yielding and becomes as aggressive as TCP
   (a simple strategy to protect itself against starvation)
5) So ISPs can't give LEDBAT a free pass just because it's LEDBAT;
   (LEDBAT will typically be as bad as TCP where there's shared congestion)
6) Within the set of all LEDBAT traffic, we still repeat TCP's sharing problem
   (LEDBAT-2 would be cooler: larger LEDBAT-2s yielding to smaller LEDBAT-2s)
7) Protocols better at yielding than LEDBAT should be automatically rewarded

Bob

At 23:51 22/10/2009, Fred Baker wrote:
>Actually, could I get you to read the ledbat 
>charter? http://www.ietf.org/dyn/wg/charter/ledbat-charter.html
>
>>line even if drops start to occur. And especially mentioning Cubic/ Reno,

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 25 Oct 2009 00:45:27 +0100

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:
>I think the current proposal (per my last message, and certainly 
>still subject to improvement!) is:
>
>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 
>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 

But thanks for trying.

Cheers

Bob

>>to go faster while background stuff temporarily goes slower. That 
>>is the opposite of TCP-friendly, which is better overall.
>>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 
>>>>traffic (or not). This is what we should mean by permanent partial deployment.
>>>>once I had made this design goal clear.
>>>>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.
>>>>>
>>>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 :-) ).
>>>
>>>>>today. Once ISPs can see rest-of-path congestion, they can actively discourage
>>>>d/actively /
>>>
>>>Done.
>>>
>>>>[phil] ok
>>>>>offered from potential connectivity partners. Meanwhile 
>>>>>end-hosts may be freed from rate restrictions where their traffic causes little
>>>>congestion.
>>>>[[[Your original had wording around this idea that has got lost 
>>>>in translation.]]]
>>>
>>>>>IP header. Any such protocol should work with minimal changes to 
>>>changes to the existing Internet, preferably working with unmodified routers."
>>>
>>>>>Additional work items could include detailing the motivations 
>>>>>for congestion exposure, a threat analysis of the subsequent 
>>>>>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.
>>>>>
>>>>>>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, 
>>>>>>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 
>>>>>>for causing congestion at the network layer. We propose a 
>>>>>>metric where all IP packets carry information about the 
>>>>>>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 
>>>>>>control the congestion their customers cause, and more 
>>>>>>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 
>>>>>>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 
>>>>>>*From:* [email-masked] 
>>>>>>[mailto:[email-masked]] *On Behalf Of [email-masked]
>>>>>>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
>>>>>>
>>>>>>---
>>>>>>
>>>>>>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 
>>>>>>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).
>>>>>>
>>>>>>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
>>>>>>to the existing network, in particular it should work with unmodified routers.
>>>>>>
>>>>>>could include detailing the motivations for congestion 
>>>>>>exposure, a threat analysis of the subsequent protocol, 
>>>>>>deployment considerations. Importantly, the proposed WG would 
>>>>>>encourage experimentation but not deliberate on how congestion 
>>>>>>resulting protocol can support differing needs at run-time,

---

From: Leslie Daigle <[email-masked]>
Date: Sun, 25 Oct 2009 17:29:29 -0400

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:
> 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...
> 
>> and stifling innovation at the transport and application layer (see 
>> 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
> 
>> TCP congestion control.
> 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
> 
>>>>>> below) and
>>>>> routers./
>>>>>>> may be freed
>>>>>>> ---------------------------------------------------------------------- 
>>>>>>>
>>>>> -- 

--

---

From: João Taveira Araújo <[email-masked]>
Date: Sun, 25 Oct 2009 23:53:45 +0000

Hi,

Here goes an attempt at making this paragraph a little less confusing by 
splitting it in two and a bit of rephrasing. The last sentence is still 
a little confusing though.

> for example, the problem statement I-D (ref below) and RFC5594).

<my attempt>
However, TCP alone provides neither the means nor the incentives for 
applications to limit the congestion they inflict on others, resulting in a
troubled coexistence between applications with differing needs.  High 
traffic applications, such as peer-to-peer or streaming video, are 
unable or unwilling to restrain themselves 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.  Such practices ostracize an entire class of 
applications for simply attempting to pool available capacity, 
consequently stifling innovation at the transport and application layer, 
as well as increasingly leading to calls for government regulations (see 
for example, the problem statement I-D (ref below) and RFC5594).
</my attempt>

Cheers,
Joao

---

From: "Ilpo Järvinen" <[email-masked]>
Date: Mon, 26 Oct 2009 11:58:52 +0200 (EET)

Me too want to put :-).

> You started out by telling me that arbitrarily increasing the window doesn't
> hurt anything

No, I didn't say that. And after rereading what I said, I'm rather sure 
that you just wanted to see it that way, I said:

"As long as no unnecessary work is not done at any bottleneck (and we 
don't have a shared resource such as a wireless channel), thoughput does 
_not_ degrade (at all!), even though many keep asserting that without much 
of a thought nowadays."

...And before that I explicitly said that I agree with you that delay 
increases.

We were talking about _throughput_ reduction after "cliff", which was 
first claimed by you and I responded to that :-). ...And then you followed 
saying that Reno/Cubic aims to that cliff. While you didn't directly claim 
that Reno/Cubic behavior then implies throughput reduction, I don't see 
why you even brought the througput up in the first place if you didn't 
want to imply that these two would be related. If it was just about delay 
increase with Reno/Cubic I agree with you.

> - you quoted Bob saying that congestion isn't a problem. I demonstrated 
> that congestion out of control is a problem.

...Right, but not for the Cubic/Reno which you in the first mail put among 
the bad ones. Cubic/Reno are not something I'd call to be "out of 
control". E.g., if you would replace those two flows of your example with 
them, no problem would occur even with the fact that they "tune to the 
cliff" (and even you seemed to agree with this with as you mentioned ACK 
clockedness which is in effect both with Cubic and Reno).

Besides, it's the loss based feedback which forces Cubic/Reno to operate 
near the cliff, not something that is built into Cubic/Reno behavior 
itself. So with ECN your original statement about them tuning to the cliff 
wouldn't be true with either but I suppose might have meant that in
your later paragraph about ECN (in fact, I think it's totally independent 
from Cubic/Reno behavior whether the tuning happens to "the cliff" or 
not, just buffer sizes and when congestion feedback is given matters).

> ISPs and their customers when they run seven Cubic/Reno TCPs in 

Here I agree with you, it is out of control how many paraller Cubic/Renos 
one opens. But I don't think this has much to do with "tuning to the 
cliff". One can take an extreme example: it is possible to open so many 
of them that all will just continue because of occassional RTOs (or for a 
moment with window of two when lucky enough). ...But again that is just 
stupid behavior and it then even becomes completely irrelevant whether 
you had FAST, Cubic or Reno there in the first place. So assuming windows 
are in such region that RTOs due to small window are not the problem, I 
don't see why Cubics/Renos wouldn't reduce their rate when experiencing 
losses and recover relatively fast without introducing _unnecessary_ 
retransmissions, preventing entry to such state where unnecessary work is 
done as multiple bottlenecks for a single flow can then only happen during 
a short transient. ...So I see how this would prove your original point 
(copied from Jain) about throughput decrease at the cliff (for the 
Reno/Cubic). If not pushed to such extreme scenario using unresponsive 
traffic like you did in you the example you provided first, the issues 
will mainly be in _delay_ (or in response time which is essentially the 
same as delay) because Cubic/Reno are, after all, responsive. 
Throughput is only affected when a flow is about to complete (and requires 
retransmissions due to losses it suffered from) but you never seemed to 
even slightly hint towards this (this is of course relatively significant 
case in the real world).

> Actually, could I get you to read the ledbat charter?
> http://www.ietf.org/dyn/wg/charter/ledbat-charter.html

You have to be reading between the lines, as it doesn't say anything about 
troughtput reduction? It talks only about delay and that it is maximized 
by the std TCP behavior. Contrary to your claims, it even admits that such 
maximizing "works well" for some types of transfers, so where you see this 
throughput reduction at the cliff?!?

Only paragraph that even remotely is discussing about throughput related 
issues is this: "When an application uses several non-rate-limited 
transport connections to transfer through a bottleneck, it may obtain a 
larger fraction of the bottleneck than if it had used fewer connections" 
(note that that non-rate-limited here does not imply fully unresponsive,
afaict if reading the whole paragraph, just "n times more aggressive" than 
std TCP). To me that certainly doesn't say that throughput reduces but 
that it is shared "unfairly" (if you let me use that not well defined 
expression) which I certainly agree.

To conclude, there is no equivalence between increase in queuing delay and 
decrease in throughput in the real world, while it certainly can happen
like you put in one of the later mails: "potentially". Of course some keep 
trying to make them fully equivalent (trying to make it less and less 
relevant to find out the actual causes of problems, just blame "the big 
bad congestion collapse" instead :-)):

http://www.postel.org/pipermail/end2end-interest/2009-September/007769.html

-- 
 i.

> > > > >also
> > > > >etc,

---

From: <[email-masked]>
Date: Mon, 26 Oct 2009 10:14:51 -0000

I think João's text is starting to head in the right direction. I especially like how he gets across that there are different applications wanting different (and sometimes conflicting) things out of the network.

I fully agree that this is something we need to get right and it isn't there yet. The trouble is there are a number of subtle aspects that need to be captured without pointing the finger of blame at any one class of applications or users... The simple fact is it is astounding that the Internet has managed to absorb growth of 8 orders of magnitude and still work as well as it does. 

Toby

> Behalf Of João Taveira Araújo
> Sent: 25 October 2009 23:54
> To: Leslie Daigle
> Cc: [email-masked]
> regulations

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 26 Oct 2009 16:06:18 +0000

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,
>>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...
>>>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.
>>>
>>>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 
>>>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.
>>>In order to avoid congestion from such applications, more 
>>>aggressive control is required in some circumstances than is 
>>>provided by standard TCP congestion control.
>>Again, 'additional' sounds like we're arguing for app-specific, 
>>which we're not.
>>
>>>Though I'm suspecting that some instances of "congestion" should 
>>>be replaced by "performance".
>>>
>>>Leslie.
>>>
>>>Bob Briscoe wrote:
>>>>Leslie,
>>>>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.
>>>>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?".
>>>>the obligatory silent observers you get these days at the IETF, 
>>>>who were sitting on their hands 
>>>>trick recursively as different size flows arrive. Ie. imagine 
>>>>three types of flows co-existing:
>>>>- small foreground 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.
>>>>>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.
>>>>>
>>>>>>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
>>>>>
>>>>>>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.
>>>>>>likely to severely limit non-re-ECN traffic. But we should 
>>>>>>leave that up to each ISP.
>>>>>>]]]
>>>>>>
>>>>>>> which allows greater freedom over how capacity is shared. 
>>>>>>> Such information could be used for many purposes, including 
>>>>>>>ability to share capacity has been paramount to its success 
>>>>>>>and has traditionally been managed through the voluntary use 
>>>>>>>of TCP congestion control. However, TCP alone is unable to 
>>>>>>>prevent bandwidth intensive applications,
>>>>>>s/bandwidth intensive applications/applications transferring 
>>>>>>high traffic volumes/
>>>>>
>>>>>>[[[Reasoning: TCP *can* limit bandwidth, but it cannot 
>>>>>>arbitrate continuously heavy use of bandwidth over time.
>>>>>>]]]
>>>>>>
>>>>>>>attempt to distribute capacity differently. The consequences 
>>>>>>>of such practices are increasingly leading to calls for 
>>>>>>>government regulations and stifling innovation at the 
>>>>>>>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/
>>>>>>>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
>>>>>>>Meanwhile end-hosts may be freed from rate restrictions where 
>>>>>>>their traffic causes little
>>>>>>congestion.
>>>>>relaxed is probably overreaching (happy to be educated 
>>>>>otherwise), and largely think the rest is covered in the "Meanwhile" sentence.
>>>>>
>>>>>>
>>>>>>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.
>>>>>
>>>>>>
>>>>>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.
>>>>>
>>>>>>
>>>>>>>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.
>>>>>>>
>>>>>>>>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, 
>>>>>>>>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 
>>>>>>>>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 
>>>>>>>>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.
>>>>>>>>
>>>>>>>>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 
>>>>>>>>perspective of the BoF. I also deleted the claim that the 
>>>>>>>>work should be transport-agnostic, as I find 'transport' an 
>>>>>>>>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 
>>>>>>>>ability to share capacity has been paramount to its success 
>>>>>>>>and has traditionally been managed through the voluntary use 
>>>>>>>>of TCP congestion control.
>>>>>>>>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 
>>>>>>>>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 
>>>>>>>>protocol to expose the expected rest-of-path congestion in the IP header.
>>>>>>>>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 
>>>>>>>>encourage experimentation but not deliberate on how 
>>>>>>>>flexibly the resulting protocol can support differing needs 
>>>>>>>>at run-time, rather than dictating a particular usage at design time.
>>>>>>>>

---

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

Meta-comment: Bob _really_should_ break the habit of quoting the whole
of the message he's responding to!

   (It wouldn't hurt if the rest of us also broke that habit.)

Bob Briscoe <[email-masked]> wrote:
> which implied we want something that can.

   An important point. We're not trying to win over the folks that want
that.

> I've changed it round (& it's a few bytes shorter):

   (Another meta-comment: It's hard to get the context, or even exactly
what Bob wants the whole BoF announcement to look like.)

> This in turn has increasingly led to calls for government regulations.

   It's really getting to be time to put this to bed: so I won't
respond to individual words and phrases...

   Generally, it's an improvement to talk about what TCP _doesn't_
take into account. At some point we'll have to explain why these
omissions are important, but it doesn't have to be here.

   It's clear enough that ISPs and other network managers _are_
deployinng the kinds of measures listed, whether or not it's clear
why they do it. There's really not much we can do in the line of
defending or attacking them here: the practices will have to be
discussed at the BoF, and the less we accept responsibility for
defending or attacking them, the better.

   Frankly, the "Problem Statement" isn't going to be in terribly
good shape at the time that folks will be reading the BoF announcement.
It's an important document; it does not deserve to be rushed. I
question whether mentioning it in the BoF announcement helps.

> The whole thing has a relentlessly negative tone I'm afraid.

   There's really not much we can do about that. Live with it!

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

   This is true; but I'm not sure we've even gotten that across to
the active participants on this list. The sort of tweaking we've
been attempting for the last week _can't_ hope to get that across.
Perhaps someone would like to prepare an agenda item on that?

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

   :^) !!!

   'Twould be a lovely agenda item...

> </2nd_Half_of_para3_on_wiki>

   (Probably I should hunt down that wiki page and do a mental diff,
but I do have other things that need to get done today...)

   I really don't know if the wiki can be a good tool for expressing
this stuff: in general, a wiki will evolve to a point where enough
differing opinions are detailed; but that evolution proceeds on its
own timescale, whereas we're facing a hard deadline for the BoF to
start and finish.

   In any case, a wiki really doesn't try for brevity, and attempts
at brevity (at the expense of completeness) aren't helping here.
Might it be better for Bob to have his own section of the wiki to
explain _exactly_ how he sees re-ecn fitting in -- where he gets
his text complete and simply posts pointers to it?

   I don't believe that posting proposed changes to "the wiki", as if
it were a WG document with a Document Editor, is working.

   Nor do I even believe that trying to have text which is all things
to all participants is a good goal to pursue here.

   Clearly, the BoF needs to happen. Almost as clearly, the BoF is
not about whether re-ecn is the right solution. It's clear to me that
we're going to have to live with a mushy problem-statement at the BoF;
so picking "the" solution would be ill-advised, even if the Tao of
BoFs didn't forbid it.

   The BoF needs instead to give IESG folks a way to judge whether
there's sufficient interest and commitment to form a Working Group,
and whether a Charter can be written that appears to have a good shot
at success. IMHO, the IESG is generally friendly to this idea; but
there's a lot of history to look back on, and the path to deployment
is unclear.

   I don't honestly know how well IESG folks understand re-ecn, but
that may not matter. We've had plenty of opportunities to explain
the basic ideas of re-ecn: we shouldn't consider success or failure
to get those ideas across at the BoG as a critical-path.

   We should present the breadth of interest; we should try to get
across _some_ progress on a Problem Statement; and we should hope
for a goodly hum on willingness to work on the problem.

   I doubt that fine-tuning the BoF announcement is a good way to
ensure _any_ of those tasks...

---

From: <[email-masked]>
Date: Mon, 26 Oct 2009 17:22:58 -0000

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

> From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
> Sent: 26 October 2009 16:06
> To: Leslie Daigle
> Cc: Eardley,PL,Philip,DEE1 R; [email-masked]
> >>It would be much better to leave it as it is than make these
changes,
> IMHO.
to
> >>>>congestion is the problem. No. No. No. Rubbish capacity sharing is
the
> problem.
important
>>>>>>==================================================================
==
> >>>>>>>of the Internet. By revealing expected congestion in the IP
header
> of every
clear
quantifiable.
> >>>>>inspired to suggestion, however.  (So, I did the mod as described
:-)
> ).
subset
> >>>>>>application behaviours to evolve that would still prevent
congestion
> collapse./
> >>>>>otherwise), and largely think the rest is covered in the
"Meanwhile"
> sentence.
that
> >>>>>changes to the existing Internet, preferably working with
unmodified
> routers."
end-hosts
> >>>>>>>>protocol to expose the expected rest-of-path congestion in the
IP
> header.
> >>>>>>>>at run-time, rather than dictating a particular usage at
design
--
> ----

---

From: <[email-masked]>
Date: Mon, 26 Oct 2009 17:43:56 -0000

{taking account of John Leslie's meta-comment about snipping text! Which
must especially be important to anyone getting the digest...}

<snip>

> Sent: 26 October 2009 17:23

That seems a little clumsy to me. I agree that we need to move back to
the idea that it is the user not the application that should be
accountable. How about 

"However, TCP fails to account for how a particular application occupies
capacity over time or which applications a user chooses to run."

> for government regulations [refs]".

Phil's version is much clearer... 

</snip>

Toby

---

From: <[email-masked]>
Date: Mon, 26 Oct 2009 17:55:50 -0000

John,

Thanks, very useful comments.

I agree that putting a lot more effort into word-smithing of the wiki is
not the best use of the ML's time - providing people can live with bob's
latest suggestion

> defending or attacking them, the better.

Agree. I think the important points are 
(1) the ISPs are doing these measures (DPI, volume capping etc). I think
discussing TCP's inadequacies is somewhat over-detailed; many of the
points being brought up are true, but even if that point was solved
(with TCP++) then it wouldn't end the reason why the ISPs deployed the
measures.
(2) the world would be much better with conex & the usages it enables.

> so picking "the" solution would be ill-advised, even if the Tao of

depending on what the revised problem statement is like, I think it
could be worth working up some succinct motivation text on the main
motivations. Whilst we don't want to cover all the possible usages of
conex, there seem 2 main things:
- capacity sharing for an ISP. This is solving a current issue in a way
that is "better" than the current mechanisms (which are DPI, volume
capping etc or putting in more bandwidth) - "better" could mean for ISPs
(simpler capacity sharing), regulators (transparency of mgt) etc
- enabling new user/application/transport behaviours by end-hosts (eg
the encouraging ledbat point)

if some nice text can be extracted / adapted from the problem statement
i-d (& Hannes one as well), then it might be worth adding this to the
wiki

Our agenda already covers the capacity sharing motivation; we'll think
about whether there's also time to cover the point about "new end-host
behaviours", or if this will dilute the focus.

> there's a lot of history to look back on, and the path to deployment

Leslie and I'll start on some Charter text. I will start with some
thoughts about the 'constraints' item on the agenda. 

I agree that the path to deployment is a very important question that
isn't clear enough. I guess this will be discussed under the
"Viability/Feasibility" agenda item. Another issue is how much the WG
(if formed) thinks about deployment, and how much it leaves this to
operators etc or until re-chartering. 

Thanks
phil