Subject: [re-ECN] draft-tschofenig-conex-ps and our recommendation for the group

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 2 Mar 2010 15:44:34 +0200

Hi all, 

we wanted to provide a bit of details of why Alissa and I worked on
draft-tschofenig-conex-ps. 

Our goal for the problem statement document was 
1) to offer a writeup that does not talk about the solution
2) to focus on one aspect of the perceived problem only. 
 
While there may be the other problems problems out there that a specific
solution can solve (e.g. denial of service attacks, trouble-shooting of
network problems) we really think that one needs to focus on one thing
at the time because otherwise you run into what I call the
HIP-effect(*).

The problem needs to be well understood and documented before one can go
forward with the next step. The lack of a clear problem statement
discussion was for me recognizable at the BOF.

Once people agree on the problem then it is interesting to capture the
state of the art as far as what tools operators are already using to
solve the problem. Since a number of operator believe they have a
problem there is a wide range of solutions they are deploying today. The
excellent writeup by Jason and Ric (see
draft-livingood-woundy-congestion-mgmt) is one example of a solution
that offers very interesting properties already (such as being protocol
agnostic). There are other solution approaches that other operators are
deploying but they are less well documented. Every solution has pros and
cons and, from what we can tell, there is no one-size fits all approach.

Unfortunately, we have not seen a lot of discussions about what is being
done and why the group considers them as insufficient. This leads to the
next point, namely to document what is not good enough with the
available techniques. If there is a specific problem identified, and the
inadequacies of the existing solutions are compelling, that argues that
there is space for new work in this area.

So, in a summary we would suggest the following approach and this is
also the  approach we will try to take as we rev our problem statement
(although there will certainly still be gaps), and there are some
elements of it in the draft-moncaster problem statement, but we wanted
to frame the thought process before posting a new version:

A) Figure out whether most people agree to a description of the problem.

(There may be multiple sub-problems.)

B) Document the state-of-the-art (and why people have chosen a certain
approaches).

C) Document the gaps that are not covered by state-of-the-art solutions
that would require additional work. For me a really important question
is what are the incentives for someone to deploy anything in addition to
draft-livingood-woundy-congestion-mgmt?

There are other ways to approach the topic but we believe that this is
the appropriate way in this case.

Ciao
Hannes & Alissa

(*): A solution that solves all problems but none really well.

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 03 Mar 2010 16:23:00 +0000

Hannes,

Yes, I could see what you were trying to do with that draft. I'd like 
draft-tschofenig-conex-ps a lot more if it talked about 
traffic-management in general rather than p2p-traffic-management. I 
know you wanted to be very specific, but p2p was too specific. 
Talking only about p2p causes allergic reactions depending on what 
the reader's interests are. There's the same problem with video 
traffic - who decides which traffic isn't worth providing capacity for?

Sally Floyd taught me well about solutions that solve all problems 
but none really well (what you call the HIP effect, but I don't like 
that association - it may be perjorative ;)

I don't think re-ECN has a jack-of-all-trades-master-of-none problem. 
It has the problem that people find it difficult to imagine know how 
much better the Internet could be. This is better described as the 
"80-20 problem". But if you have a hack that solves 80% of the 
problem, what if it actually only solves 40% or 60% of the problem 
longer term - because we don't have a good handle on how broad the 
problem will really be in the future?

The classic example is NATs. They seemed to solve 80% of the 
addressing problem when they were first deployed, but they have 
prevented a lot of other things happening - ie. how we define what is 
included in 100% of the problem determines whether we've solved 80% 
or only 10%.

Similarly, some might say DPI solves 80% of the traffic management 
problem, but it has created other undesirable interactions. DPI 
doesn't encourage mutual co-operation between willing transports - so 
does it really solve 80% or 30% or 10%?

I thought draft-moncaster-conex-problem hit about the right spot - it 
focuses on the problem of accountability for causing congestion. 
Admittedly, it mentions some other things ConEx could solve, but it 
keeps focus on the one problem fairly well.

Incidentally, Rich Woundy has done a presentation on what additional 
benefits re-ECN would provide over ComCast's solution:
It's under the link to all the speaker presentations in the article 
here: <http://giic.org/>
Specifically: <http://giic.org/pdf/GIIC-CapShare-01-Woundy-Comcast.pdf>

HTH

Bob

At 13:44 02/03/2010, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>_______________________________________________
>re-ECN mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 04 Mar 2010 10:55:55 +0200

Hi Bob,

Bob Briscoe wrote:
> know you wanted to be very specific, but p2p was too specific. Talking 
> only about p2p causes allergic reactions depending on what the 
> reader's interests are. There's the same problem with video traffic - 
> who decides which traffic isn't worth providing capacity for?

You are completely right that the description has to be independent of 
the type of traffic, at least to a certain extend.
The reason why P2P is mentioned a lot is that today's problems are 
largely caused by P2P traffic rather than other traffic but I noticed 
recent surveys indicating that it is shifting again.

A small note: The type of traffic is not totally irrelevant since 
various solutions being deployed today assume that you can shift the 
transfer of downloads to a later time. This might work well for file 
downloads where the user may be willing to wait but not for real-time 
traffic.
>
> Sally Floyd taught me well about solutions that solve all problems but 
> none really well (what you call the HIP effect, but I don't like that 
> association - it may be perjorative ;)
You don't like me to call it HIP effect or you don't like me saying that 
at least one problem area has to be described well enough for folks to 
agree?

> included in 100% of the problem determines whether we've solved 80% or 
> only 10%.

Sounds nice but the NAT case shows that the industry works different.

> does it really solve 80% or 30% or 10%?

I agree with you that a desirable solution is protocol agnostic.

Even if we accomplish to design such a solution (which is not too 
complicated given the fact that Comcast already deploys such a solution 
today) I still believe that many operators would still buy a DPI 
solution because they are interested in the other properties (such as 
charging and analysis). Hence, you cannot see the DPI aspect in 
isolation and to believe that DPI will go away when you have a protocol 
agnostic solution for traffic management is misguided, I believe 
(otherwise you would not have seen some DPI vendors being supportive of 
the work in this group if their main cash cow could go away).

> Specifically: <http://giic.org/pdf/GIIC-CapShare-01-Woundy-Comcast.pdf>

Thanks for the pointer. It would be nice if folks could agree (a) that 
there is a problem and (b) about the specific gaps of the currently 
deployed mechanisms.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 04 Mar 2010 10:56:04 +0200

From your mail I believe that you would like to approach the topic in a 
different way, namely similar to what I had suggested as a note in 
http://www.ietf.org/mail-archive/web/re-ecn/current/msg00328.html

When I read the draft-moncaster-conex-problem I had gotten that this is 
essentially the introduction chapter of reECN rather than attempt to 
investigate the larger picture.

The story is as follows: Instead of going through a lengthy analysis of 
what the requirements are, what people do in the industry, etc. you just 
standardize a solution and see what happens. In my opinion this is the 
way how the work in LEDBAT came to exist. The positive side about LEDBAT 
was that the algorithm was already deployed and hence standardizing it 
was seen as more natural instead of going through a more lenghty route 
of investigating the entire space.

The ALTO work was not all that different. The group got scheduled with a 
very specific solution approach in mind. I was in fact stating several 
times that the requirements and the problem statement and requirements 
work was a waste of time.

Do you think that this would be a better route for the congestion 
exposure work in the IETF?

Ciao
Hannes

PS: You created the expectation that reECN would change the whole 
Internet. That obviously raised the bar a bit.

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 4 Mar 2010 15:14:04 +0000

Bob,

Couple of thoughts inline.

On Mar 3, 2010, at 4:23 PM, Bob Briscoe wrote:
> I thought draft-moncaster-conex-problem hit about the right spot -  
> it focuses on the problem of accountability for causing congestion.  

I think there is a lot to like in draft-moncaster-problem, and it does  
focus to some extent on congestion accountability. But I think there  
could be a clearer statement of what problem congestion accountability  
would be solving. From reading the problem statement and looking at  
Rich's slides, there seem to be three congestion-related problems that  
congestion exposure could help to solve

1) LEDBAT-style congestion control is not currently incentivized  
because operators who use volume accounting treat apps that use it  
just like everything else. This is thoroughly discussed in draft- 
moncaster-problem.

2) Operators have no way to know, within the network, the volume of  
congestion being created by other networks, and therefore no way to  
hold those other networks accountable. This is not so thoroughly  
discussed in draft-moncaster-problem.

3) Users/apps need more information about congestion in order to be  
able to respond better. This is not really discussed in draft- 
moncaster-problem.

I think it would be helpful for the group to have some sense of which  
subset of these problems we are trying to solve. Then, ticking through  
the mechanisms that already exist to solve the problems and showing  
how they are deficient could lead to the conclusion that the  
congestion exposure work is warranted (draft-moncaster-problem already  
does this to some extent, but in my reading at least the link between  
the stated problems, the inadequacies of the existing solutions, and  
the reasons why conex would improve the situation is somewhat weak).

Alissa

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 05 Mar 2010 17:18:12 +0000

Hannes,

At 08:55 04/03/2010, Hannes Tschofenig wrote:
>Hi Bob,
>
>Bob Briscoe wrote:
>>Hannes,
>>
>>Yes, I could see what you were trying to do with that draft. I'd 
>>like draft-tschofenig-conex-ps a lot more if it talked about 
>You are completely right that the description has to be independent 
>of the type of traffic, at least to a certain extend.
>largely caused by P2P traffic rather than other traffic but I 
>noticed recent surveys indicating that it is shifting again.

[BB]: Yes, all the studies I've seen in the last year or so 
(scholarly and from equipment vendors) have shown p2p is staying 
about constant in absolute terms, but therefore reducing in relative 
terms as video grows.

Many ISPs are investing in capacity to deliver their own value-added 
services, often given priority using Diffserv. But when customers get 
their services over-the-top (OTT) as best-efforts (BE), they can use 
the same capacity, because BE borrows from the unused capacity the 
ISPs are provisioning for their premium value added services.

But, now that the growth is in video, I think many ISPs believe their 
customers will be willing to pay more for basic bit-transport even if 
they don't subscribe to the ISP's own services. I.e. they assume 
there is real cash behind the growth in demand for video streaming 
bytes, whereas they didn't see much real cash behind demand for p2p 
file-sharing bytes.

However, if cash flows don't match up to increasing costs, there 
won't be an easy way for the ISP to decide which traffic users value 
least any more.

That's why I believe ConEx is important - it's intended to encourage 
machinery in operating systems & apps to give different weights to 
different apps, rather than the ISP making choices.

P2p was an easy target. Altho people don't like their ISP making 
their choices, if the customer had had to choose, they would have 
often reduced p2p themselves, rather than slowing down their 
streaming, Web, VoIP, email etc.

>downloads where the user may be willing to wait but not for real-time traffic.

[BB]: You gain considerably from timeshifting even by seconds (or 
even less). The study linked below got 100% more video through the 
same capacity by multiplexing variable bit-rate encoded videos which 
all timeshifted away from congested times (when all the hard scenes 
in each video happened to coincide).
<http://www.ingentaconnect.com/content/ind/ijiptijipt/2009/00000004/00000001/art00007>
The timeshifting was solely within the buffering time of the videos.

>>but none really well (what you call the HIP effect, but I don't 
>>like that association - it may be perjorative ;)
>You don't like me to call it HIP effect or you don't like me saying 
>that at least one problem area has to be described well enough for 
>folks to agree?

I don't like calling it the HIP effect.

>>I don't think re-ECN has a jack-of-all-trades-master-of-none 
>>problem. It has the problem that people find it difficult to 
>>imagine know how much better the Internet could be. This is better 
>>described as the "80-20 problem". But if you have a hack that 
>>solves 80% of the problem, what if it actually only solves 40% or 
>>60% of the problem longer term - because we don't have a good 
>>handle on how broad the problem will really be in the future?
>>
>>prevented a lot of other things happening - ie. how we define what 
>>is included in 100% of the problem determines whether we've solved 
>>80% or only 10%.
>

With ConEx, we're trying to learn from the mistakes with NATs by 
recognising the ISPs' economic concerns and standardising something 
that gives ISPs information they cannot get right now: the 
incremental cost of traffic. This provides an architecture for 
traffic management that will give ISPs sufficient control over their 
costs, but without having to violate the architecture.

>>doesn't encourage mutual co-operation between willing transports - 
>>so does it really solve 80% or 30% or 10%?
>
>complicated given the fact that Comcast already deploys such a 
>solution today) I still believe that many operators would still buy 
>a DPI solution because they are interested in the other properties 
>(such as charging and analysis). Hence, you cannot see the DPI 
>aspect in isolation and to believe that DPI will go away when you 
>have a protocol agnostic solution for traffic management is 
>misguided, I believe (otherwise you would not have seen some DPI 
>vendors being supportive of the work in this group if their main 
>cash cow could go away).

Indeed. There are other reasons for using DPI than controlling costs...

For instance, if cellular operators use ConEx, I suspect it will be 
to complement their DPI. DPI will tell them the value of sessions and 
ConEx will tell them the cost of traffic, then they will maximise 
(value minus cost).

But the fixed ISP market is commoditising much more rapidly. If an 
ISP tried to extract more cash from a session that it inferred was 
more valuable (using DPI), the customer would just switch to another 
ISP. It's the classic outcome of competition: driving prices down 
towards the cost of provision. Even if a customer values a session a 
lot higher than it costs to deliver, no ISP can capture that extra 
value because others can undercut them and still cover their costs.

That's why I figured it was correct for the IETF to focus only on the 
incremental cost of traffic (ConEx). If a provider can extract more 
value using DPI, good luck to them. But that's icing on the cake, 
whereas cost is the cake itself - cost is the essential and neutral 
economic factor that any industry needs to understand in order to function.

When we first evaluated the early DPI offerings, we advised that most 
of the proposed uses for DPI were reasonable (market analysis, rapid 
development of new protocol handlers, anomaly detection etc). But we 
advised that DPI would not be a long term solution for traffic 
management and control. Traffic management needed to be able to work 
for all traffic, whether encrypted or not. Whereas the other uses of 
DPI were valid because they were either optional or consensual.

>>Incidentally, Rich Woundy has done a presentation on what 
>>additional benefits re-ECN would provide over ComCast's solution:
>Thanks for the pointer. It would be nice if folks could agree (a) 
>that there is a problem and (b) about the specific gaps of the 
>currently deployed mechanisms.

Yes. Rich's presentation in the Hiroshima BoF largely used the same 
material as his GIIC slides linked above, in order to hilite the gaps 
that Comcast couldn't do with Capshare but would be able to do with 
ConEx. I agree that we all need to focus more on those gaps.

Cheers

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 05 Mar 2010 18:08:51 +0000

Alissa,

>just like everything else. This is thoroughly discussed in draft- 

yes

>discussed in draft-moncaster-problem.

Yes.
And you're right that draft-moncaster-problem doesn't do this aspect 
as much justice.

>able to respond better. This is not really discussed in draft- 

Don't agree with this one. It's not actually true to say users/apps 
don't have congestion info - they have full visibility of their congestion.

But this congestion information has no *significance* to users/apps, 
while they know that networks cannot see it.

>the reasons why conex would improve the situation is somewhat weak).

OK. Agreed.
We also need to make sure this same approach comes across in the BoF 
presentations.

 From Rich's presentation, we have the following that match your 
list, and add to it:
==Requirements for a long term solution:==
a) Incentivize customer-directed prioritization of application bandwidth usage
b) Avoid 'cat and mouse game' with the detection and mitigation of 
specific protocols
c) Enable transparency of network operation for current and future applications
d) Support growth in per-customer average and peak bandwidth
e) Avoid uneconomic capacity upgrades that benefit only 5% of heavy 
usage customers
==Advantages of re-ECN over FairShare:==
f) Re-ECN enables end-to-end congestion management
g) Re-ECN signals the presence of congestion to user applications and 
to all devices on the network path
h) Re-ECN enables additional user and/or application responses to congestion
i) Re-ECN enables DDoS mitigation and other capabilities

a) = your #1)
b) ConEx is not unique in this respect
c) = perhaps an additional particularly strong point of ConEx?
d) & e) supply side strengths of ConEx
f) = your #2)
g) = your #3) but I say the Internet already does this well
h) = your #1 again
i) another strength of ConEx, but only to be mentioned in passing;

We're left with the following unique selling points:
a) Incentivize customer-controlled prioritization of app bandwidth usage
c) Enable unambiguous transparent network operations for current & future apps
d) Drive capacity investment where financially warranted
f) Enable e2e congestion mgmt between networks as well as by single networks
i) Enable DDoS mitigation [only to mention in passing]

HTH

Bob

>>>solution can solve (e.g. denial of service attacks, trouble- shooting of

---

From: <[email-masked]>
Date: Fri, 5 Mar 2010 19:27:37 -0000

I think reason (2) is the key one - the inter-network aspect. This is
the new thing. 
If the only problem of interest is an intra-network one (eg if
congestion is always in just one network), then there will be several
possible solutions. The livingwood draft documents an interesting one
for instance. DPI-based solutions would be another method of different
interest. can imagine conex-based solutions as well (see moncaster &
other drafts).

----

Looking at the list of "requirements for a solution" prompts the thought
that we should distinguish two things:

- the conex "building block" - the ability for any node to see the
rest-of-path congestion (& the whole path congestion)
- the solutions to various aspects of 'congestion mgt' that can be built
using the conex "building block"

The conex draft charter proposes work on the first of these (ie to
standardise the IP header bits so that whole-path congestion info is
exposed (visible) to all nodes on the path, and to define a TCP-based
mechanism that allows a TCP destination to tell the source the
whole-path info, & hence the IP header can be set by the source)

The conex draft charter only proposes a little work on the second of
these. This work item is to encourage experiments on some "use cases"
and document about them. I guess the "use cases" would be tests towards
a solution (to some aspect of congestion mgt) that might get deployed by
an operator. 

We should be clear: the charter doesn't propose to standardise a full
solution that would get deployed. Rather it standardises a capability
which would be used to build a solution. 

Not sure if everyone will agree with this!

phil

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bob Briscoe
> Sent: 05 March 2010 18:09
> To: Alissa Cooper
> Cc: [email-masked]
> Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our 
> recommendation for the group
> 
> 
> Alissa,
> 
> additional 
> >>benefits re-ECN would provide over ComCast's solution: It's 
> under the 
> >>link to all the speaker presentations in the article
> >>here: <http://giic.org/>
> >>Specifically: 
> >><http://giic.org/pdf/GIIC-CapShare-01-Woundy-Comcast.pdf>
> >
> >because operators who use volume accounting treat apps that 
> use it just 
> >like everything else. This is thoroughly discussed in draft- 
> >moncaster-problem.
> 
> yes
> 
> 
> >the mechanisms that already exist to solve the problems and 
> showing how 
> >they are deficient could lead to the conclusion that the congestion 
> >exposure work is warranted (draft-moncaster-problem already 
> does this 
> >to some extent, but in my reading at least the link between 
> the stated 
> >problems, the inadequacies of the existing solutions, and 
> the reasons 
> >why conex would improve the situation is somewhat weak).
> 
> OK. Agreed.
> >>>While there may be the other problems problems out there that a 
> >>>specific solution can solve (e.g. denial of service 
> attacks, trouble- 
> >>>shooting of network problems) we really think that one 
> needs to focus 
> >>>on one thing
> >>>The problem needs to be well understood and documented 
> before one can 
> >>>go forward with the next step. The lack of a clear problem 
> statement
> >>>Once people agree on the problem then it is interesting to capture 
> >>>the state of the art as far as what tools operators are 
> already using 
> >>>to solve the problem. Since a number of operator believe 
> they have a
> >>>Unfortunately, we have not seen a lot of discussions about what is 
> >>>being done and why the group considers them as insufficient. This 
> >>>leads to the
> >>>also the  approach we will try to take as we rev our problem 
> >>>statement (although there will certainly still be gaps), and there 
> >>>are some elements of it in the draft-moncaster problem 
> statement, but 
> >>>we wanted
> >>>B) Document the state-of-the-art (and why people have chosen a 
> >>>certain approaches).
> >>>
> >>>C) Document the gaps that are not covered by state-of-the-art 
> >>>solutions that would require additional work. For me a really 
> >>>important question
> >>>There are other ways to approach the topic but we believe 
> that this 
> >>>is the appropriate way in this case.
> >>>
> >>>Ciao
> >>>Hannes & Alissa
> >>>

---

From: Alissa Cooper <[email-masked]>
Date: Sun, 7 Mar 2010 20:47:29 +0000

Phil and Bob,

On Mar 5, 2010, at 7:27 PM, <[email-masked]> <[email-masked] 
 > wrote:

> interest. can imagine conex-based solutions as well (see moncaster &

This is, I think, what Hannes and I have been trying to elucidate.  

>> i) Enable DDoS mitigation [only to mention in passing]

I think the list is more or less on target -- but identifying all of  
the great things about conex (the selling points) is not the same as  
identifying the problem that the work is supposed to solve. I'm not  
saying that there isn't a need to emphasize the selling points, but I  
am saying that if the selling points are in the problem statement,  
there needs to be some demonstration of the problem that they solve.  
Thus far, the links between the problems of lack of transparency and  
inter-network congestion management have not been so strongly linked  
to (c) and (f), respectively, and (i) might better be saved for later  
so as not to distract.

But, if the central problem is that there's no way to manage inter- 
network congestion as Phil says, that's what the problem statement  
should focus on, and not all of these other things. Neither of the  
drafts do that right now.

I'm not trying to be critical, I'm just hoping to get us to a place  
where the IESG sees the value of the work.

> a solution (to some aspect of congestion mgt) that might get  

I don't see anything wrong with this approach. The use cases are bound  
to come up all the time though, since it can sometimes be difficult to  
conceptualize the building block without an example of what you would  
do with the building block. That's probably also why we end up with  
solutions discussions in problem statement documents. :)

Alissa

>>>>> agnostic). There are other solution approaches that other  
>>>>> operators
>>>>> are

---

From: Leslie Daigle <[email-masked]>
Date: Sun, 07 Mar 2010 18:33:51 -0500

Hi,

I think this

[Alissa wrote:]
 > I think the list is more or less on target -- but identifying all of the
 > great things about conex (the selling points) is not the same as
 > saying that there isn't a need to emphasize the selling points, but I am
 > saying that if the selling points are in the problem statement, there
 > needs to be some demonstration of the problem that they solve.

is a very fair critique of where the documents & discussion stand today.

The 3 things on the table, that we keep mixing together and seem not to 
be crisp about, are:

	1.  Congestion exposure -- a proposed, generative
	    technology.  A building block, as Phil said.
	    This is where the problem statement should focus.

	2.  Potential applications and solutions that can
	    be built with a congestion exposure technology
	    in place.  These are important to see in order to
	    understand usefulness of the technology, but they
	    are not the "it" for which the problem statement
	    should be written.

	3.  re-ECN -- which is an excellent proof point that
	    congestion exposure technologies are possible, that
	    desirable effects can be achieved using them, and
	    applications and solutions can be built on them.

Whether it's how we say it, or how it gets heard -- when we talk about 
things that have been built on re-ECN, we get miles away from "1." -- 
congestion exposure and its problem statement.

Where we want to get to with CONEX is a solid problem statement for 1., 
and a plan to develop or shake out an actual implementation -- whether 
it starts from re-ECN or not.

[Elsewhere, I wrote:]
> 
> My personal cut on the CONEX work statement, separating out the
> technology specification from its potential uses:
> 
> Flow-rate fairness is acknowledged to provide a "rough, simple fairness
> model" and is also acknowledged to have its limitations [RFC5290]. It is
> not possible to ensure a fair share of aggregate capacity through
> end-to-end congestion control alone. However, addressing this
> shortcoming in application-, service- or network-specific ways leads to
> considerable complexity in network management and undermines the general
> applicability of the Internet.
> 
> The purpose of the CONEX working group is to develop a mechanism by
> which IP datagrams can signal the total rest-of-path congestion that
> they are expecting along the entire path they are traversing. This
> information is currently only visible at the transport layer in the end
> systems.
> 
> Once any node can see the impact it causes (and suffers) by sending or
> forwarding packets, it will be possible for nodes to make choices based
> on expected conditions, enabling a more sophisticated overall congestion
> management spanning multiple networks and without getting into
> application- or service-specific rules.
> 
> The text above describes congestion exposure, the intended work of
> CONEX.  Separately, potential outcomes of this more sophisticated
> congestion management include tools that exploit the CONEX output to
> mitigate distributed denial of service (DDoS) attacks; simplify
> differentiation of quality of service (QoS); police compliance to
> congestion control; and don't require compute-intensive (and
> questionably-appropriate) DPI practices.
> 
> 
> 
> 
> The intended purpose of CONEX is to develop a generative technology:
> building blocks to allow more sophisticated and network-sensitive
> congestion management than is possible with the data available to nodes
> today.   This is a good way to architect for future-proof networking, if
> you believe in open, best-effort packet transmission networking as
> opposed to virtual circuits.  It does make a challenge for determining
> "deployability".  ISPs will deploy solutions, not technology:  solutions
> enabled by the CONEX building blocks.
> 
> 
> 
> 
> So, what do we have?
> 
> We have proof of concept that congestion exposure works:  the research
> work that Bob Briscoe, BT and others have done on re-ECN demonstrates
> that it is possible to implement congestion exposure, and build the
> types of tools outlined above.
> 
> We have technical experts from ISPs acknowledging that it would be nice
> to have tools that recognize conditions beyond the edges of their own
> networks.
> 
> 
> 
> What is missing?
> 
> While re-ECN demonstrates the validity of the concept, it is not clear
> if it is the "right" choice for the overall Internet, and what would be
> the correct engineering choices in its specification in order to ensure
> that it aligns well with other TCP specifications underway (e.g.,
> multipath TCP).
> 
> 
> Personally, I don't have answers to those questions -- I believe they
> are open.  I also believe that the only environment that can find the
> answers is the IETF. This is not research any longer. re-ECN is not
> something that should be specified and deployed by a private interest.
> Whether or not it plays well with other protocols requires broader input
> from engineers from many different angles, which is what a WG
> environment is supposed to provide.

Leslie.

Alissa Cooper wrote:
> Phil and Bob,
> 
> On Mar 5, 2010, at 7:27 PM, <[email-masked]> 
> <[email-masked]> wrote:
> 
> I think the list is more or less on target -- but identifying all of the 
> great things about conex (the selling points) is not the same as 
> saying that there isn't a need to emphasize the selling points, but I am 
> saying that if the selling points are in the problem statement, there 
> needs to be some demonstration of the problem that they solve. Thus far, 
> the links between the problems of lack of transparency and inter-network 
> congestion management have not been so strongly linked to (c) and (f), 
> respectively, and (i) might better be saved for later so as not to 
> distract.
> 
> But, if the central problem is that there's no way to manage 
> inter-network congestion as Phil says, that's what the problem statement 
> conceptualize the building block without an example of what you would do 
> with the building block. That's probably also why we end up with 

-- 

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

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 08 Mar 2010 22:52:55 +0000

Alissa,

I agree multi-domain could be brought out more. But I don't believe 
it can or should be the focus. Imagine a doc that focused on 
multi-domain congestion accountability. It would have to start by 
explaining what congestion accountability is and why it's important. 
Only once we have the primary new idea - the congestion metric - can 
we introduce the secondary idea of using it between provider 
networks, not just between provider and customer.

As Rich freely admits, the Comcast solution doesn't actually measure 
congestion. It measures per-customer volume during high utilisation, 
which may be somewhat related to congestion. As the doc says, that 
doesn't incentivise low congestion transports like LEDBAT. That 
proves that current network technology doesn't really have the 
wherewithall to measure congestion - the primary unique contribution of ConEx.

Regarding setting aside DoS aspects. I imagine one para somewhere 
near the end saying, "This doc focuses on the primary contribution 
ConEx claims to provide: accountability for contributing to 
congestion. ConEx has also been claimed to help with the other 
Internet problems listed below, along with references to further 
reading for those interested:
- mitigating DDoS [xxx]
- preventing congestion collapse [yyy]
- etc"

We're getting out of time for updating the prob statement before the 
deadline. But this conversation is still v useful for focusing the 
materials to be used in the BoF.

Bob

At 20:47 07/03/2010, Alissa Cooper wrote:
><[email-masked] > wrote:
>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 08 Mar 2010 23:21:25 +0000

Hannes,

At 08:56 04/03/2010, Hannes Tschofenig wrote:

> From your mail I believe that you would like to approach the topic 
> in a different way, namely similar to what I had suggested as a 
> note in http://www.ietf.org/mail-archive/web/re-ecn/current/msg00328.html
>
>When I read the draft-moncaster-conex-problem I had gotten that this 
>is essentially the introduction chapter of reECN rather than attempt 
>to investigate the larger picture.

I believe the intention was to try to describe why a protocol that 
exposes congestion is necessary. However, given re-ECN is the only 
example of such a thing, an abstract problem statement understandably 
needs to use re-ECN as the example.

>The story is as follows: Instead of going through a lengthy analysis 
>of what the requirements are, what people do in the industry, etc. 
>you just standardize a solution and see what happens. In my opinion 
>this is the way how the work in LEDBAT came to exist. The positive 
>side about LEDBAT was that the algorithm was already deployed and 
>hence standardizing it was seen as more natural instead of going 
>through a more lenghty route of investigating the entire space.
>
>The ALTO work was not all that different. The group got scheduled 
>with a very specific solution approach in mind. I was in fact 
>stating several times that the requirements and the problem 
>statement and requirements work was a waste of time.
>

The specific solution approach works for protocols like LEDBAT & 
ALTO. But with ConEx it's a much more general proposition that seems 
to need to change IP. IMO, that warrants an attempt to explain the 
problem being addressed, and not solely from the perspective of one solution.

I believe some on the IESG were grateful that there was a problem 
statement to read.

Nonetheless, we also need to show that a concrete solution exists. 
And we need to be honest that there isn't much chance that a very 
different solution will address the same problem, because it took 
years to find even one way to address the problem that would be 
incrementally deployable etc. But we should expect that a w-g will be 
able to improve the proposed solution (as is happening with LEDBAT & ALTO).

>Internet. That obviously raised the bar a bit.

Yes. But creating expectations was somewhat justified... It offers an 
e2e control model for sharing capacity & most aspects of QoS with 
ultimate control in the network. It offers the potential to mitigate 
DDoS. It could even potentially drive multi-access control of access 
networks at L2. People are having thoughts on using it within PWEs, 
PCE etc and possibly for traffic engineering.

It wouldn't be worth changing IP unless it was for something that 
could have a big impact and could be useful for more than originally envisaged.

Bob

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 10 Mar 2010 10:39:56 +0200

Hi Bob, 

Alissa will likely repond to your mail but I had to add my notes here as
well. 

>Alissa,
>
>I agree multi-domain could be brought out more. But I don't 
>believe it can or should be the focus. Imagine a doc that 
>focused on multi-domain congestion accountability. It would 
>have to start by explaining what congestion accountability is 
>and why it's important. 
>Only once we have the primary new idea - the congestion metric 
>- can we introduce the secondary idea of using it between 
>provider networks, not just between provider and customer.

But if one of the core benefits of reECN over Comcast's FairShare is the
multi-domain usage then you better describe that benefit. 

In general, if you cannot explain a benefit easily to people then you
will have a hard time to "sell" it. 
The problem is not really with educating the research and the
standardization community but those who buy the products and operate
networks. To be honest, I see it as quite difficult for a lot of people
(from the operator community) to understand why they shouldn't invest in
DPI for congestion management and to better use a protocol agnostic
mechanism.

>
>As Rich freely admits, the Comcast solution doesn't actually 
>measure congestion. It measures per-customer volume during 
>high utilisation, which may be somewhat related to congestion. 
>As the doc says, that doesn't incentivise low congestion 
>transports like LEDBAT. That proves that current network 
>technology doesn't really have the wherewithall to measure 
>congestion - the primary unique contribution of ConEx.

This is probably more a terminology problem rather than something else
IMHO. 

The FairShare determines pre-congestion within selected nodes and then
starts marking to avoid running into a congestion situation. 

>
>Regarding setting aside DoS aspects. I imagine one para 
>somewhere near the end saying, "This doc focuses on the 
>primary contribution ConEx claims to provide: accountability 
>for contributing to congestion. ConEx has also been claimed to 
>help with the other Internet problems listed below, along with 
>references to further reading for those interested:
>- mitigating DDoS [xxx]

There might be some value in including references but the DDoS aspect
has not received a lot of attention and the community on this list might
be the wrong audience anyway. 

>
>We're getting out of time for updating the prob statement 
>before the deadline. But this conversation is still v useful 
>for focusing the materials to be used in the BoF.

Yep. I think we are getting there. 

Ciao
Hannes

>>inter-network congestion management have not been so strongly 
>linked to 
>>(c) and (f), respectively, and (i) might better be saved for later so 
>>as not to distract.
>>
>>>Looking at the list of "requirements for a solution" prompts the 
>>>thought that we should distinguish two things:
>>>
>>>- the solutions to various aspects of 'congestion mgt' that can be 
>>>built using the conex "building block"
>>>
>>>and document about them. I guess the "use cases" would be tests 
>>>towards a solution (to some aspect of congestion mgt) that might get 
>>>deployed by an operator.
>>
>>>>usage customers ==Advantages of re-ECN over FairShare:==
>>>>>>>problem there is a wide range of solutions they are deploying 
>>>>>>>today. The excellent writeup by Jason and Ric (see
>>>>>>>that offers very interesting properties already (such as being 
>>>>>>>protocol agnostic). There are other solution approaches 
>that other 
>>>>>>>operators are deploying but they are less well documented. Every 
>>>>>>>solution has pros and cons and, from what we can tell, 
>there is no 
>>>>>>>one-size fits all approach.
>>>>>>>
>>>>>>>
>>>>>>>leads to the next point, namely to document what is not good 
>>>>>>>enough with the available techniques. If there is a specific 
>>>>>>>problem identified, and the inadequacies of the existing 
>solutions 
>>>>>>>are compelling, that argues that there is space for new work in 
>>>>>>>this area.
>>>>>>>
>>>>>>>important question is what are the incentives for someone to 
>>>>>>>deploy anything in addition to

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 10 Mar 2010 15:19:22 +0000

Hannes,

Agree with your other comments, but one stands out...

>starts marking to avoid running into a congestion situation.

If one transport (e.g. LEDBAT) can contribute a lot less to 
congestion than another, while sending more volume during high 
utilisation,... then FairShare is using a proxy for a congestion 
metric that is not sufficient. Don't get me wrong, I think FairShare 
is a great step forward. But we all agree FairShare doesn't create 
the incentives to use LEDBAT-like transports, which proves 
volume-during-high-utilisation is not an ideal proxy for a congestion metric.

We have a crisis of people's imaginations for how much further we can 
go by extending approaches like LEDBAT - we need to show this with 
some real code I guess.

This isn't terminology. It's because we, as a community, have a weak 
understanding of what can be done during millisecond timescales by 
computers. Instead we think in terms of utilisation because it is 
measured at human timescales averaged over minutes. And we find it 
difficult to imagine a wide range of different responses to 
congestion, because in practice we have largely experienced just two 
dominant modes: TCP and unresponsive.

Bob

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 11 Mar 2010 21:06:22 +0000

Hi Bob,

Replies inline...

On Mar 8, 2010, at 10:52 PM, Bob Briscoe wrote:

> it can or should be the focus. Imagine a doc that focused on multi- 
> domain congestion accountability. It would have to start by  

I think it's fine to introduce the general concept before a more  
specific concept. But no matter what, the problem statement needs to  
start with the problem -- not the solution. Congestion accountability  
is a solution.

> wherewithall to measure congestion - the primary unique contribution  

Agreed (I disagree with Hannes on this a little bit).

> - preventing congestion collapse [yyy]

Could be fine, I just think we should focus on getting the core right  
first.

Alissa

>>> towards
>>>>>>> protocol
>>>>>>> inadequacies of the existing solutions are compelling, that  
>>>>>>> argues
>>>>>>> that

---

From: Jason Livingood <[email-masked]>
Date: Fri, 12 Mar 2010 14:14:56 -0500

A few comments inline below.

-- Jason

> DPI for congestion management and to better use a protocol agnostic

Well, such a system is certainly less expensive that deploying DPI.  And
ISPs like any commercial organization are sensitive cost. ;-)
 
> starts marking to avoid running into a congestion situation.

What Hannes says is largely accurate, but the system by no means *avoids*
congestion.  Congestion can still occur; it is simply that the system
distributes the effects of such congestion to those few flows (users)
responsible for contributing the most to the heavy utilization.  This is
highly beneficial to the ISP, as when congestion effects strong affect users
who were not those primary traffic contributors you tend to have
dissatisfaction and get phone calls from end users, etc.

---

From: Jason Livingood <[email-masked]>
Date: Fri, 12 Mar 2010 14:20:59 -0500

A few comments inline in this message as well.

-- Jason

> volume-during-high-utilisation is not an ideal proxy for a congestion metric.

I don't think we've fully considered all of the interactions between our two
FairShare traffic classes (Priority Best Effort, PBE, and Best Effort, BE)
and LEDBAT use.  One alternative may be to always classify LEDBAT traffic as
BE and, if so, possibly also to not consider it when scanning for flows to
mark down from PBE to BE during times of pre-congestion / near-congestion.
Another incentive may be to subtract BE bytes from being counted against
monthly byte usage limits (again, speaking hypothetically).

But Rich may have some thoughts here as well.

---

From: Jason Livingood <[email-masked]>
Date: Fri, 12 Mar 2010 14:24:01 -0500

I have noticed I have completely bizarre sentence in here that I should
correct.

> dissatisfaction and get phone calls from end users, etc.

Last sentence should say:
This is highly beneficial to the ISP, as when congestion effects strongLY
IMPACT users who were not those primary traffic contributors you tend to
have dissatisfaction and get phone calls from end users, etc.

---

From: Matthew Ford <[email-masked]>
Date: Sun, 14 Mar 2010 12:52:31 +0000

Hi Jason, one comment, inline.

   - Mat

On 12/03/2010 19:20, Jason Livingood wrote:
> On 3/10/10 10:19 AM, "Bob Briscoe"<[email-masked]>  wrote:
>

How do you identify it?

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 18 Mar 2010 02:31:04 -0400

I think FairShare could be adapted to leverage congestion volume instead
of (and/or in addition to) total volume. But I think we still need Conex
to make this work.

FairShare is a network policing mechanism. Conex is a network
measurement and packet marking mechanism. They can place nicely together
(I believe) but they are still independent mechanisms.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Matthew Ford
Sent: Sunday, March 14, 2010 8:53 AM
To: [email-masked]
Subject: Re: [re-ECN] draft-tschofenig-conex-ps and our recommendation
for the group

   - Mat

How do you identify it?

---

From: Jason Livingood <[email-masked]>
Date: Sun, 21 Mar 2010 18:50:04 -0400

>> and LEDBAT use.  One alternative may be to always classify LEDBAT traffic as

Great question, but no clear answer yes. We'll have to see how LEDBAT
develops.  Certainly a host could self-identify traffic as LEDBAT.

Jason

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 22 Mar 2010 18:14:31 +0000

Jason,

>develops.  Certainly a host could self-identify traffic as LEDBAT.

There lie monsters.
Then you encourage developers to self-identify traffic as LEDBAT that 
doesn't actually behave like LEDBAT. Or it is LEDBAT trying to behave 
nicely, but not actually able to succeed.

Rather than go by what the traffic *claims* to be, go by how much it 
actually succeeds in not contributing to congestion. That's what 
ConEx was designed for.

Absent ConEx, it's nearly impossible to get a measure that both sides 
won't argue about.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 22 Mar 2010 18:23:29 +0000

Alissa,

Sorry, I missed your earlier post... one response...

>start with the problem -- not the solution. Congestion accountability

A need for congestion accountability is certainly not what most 
people think the problem is. But it is actually a very precise 
statement of what the problem turns out to be when you delve deeply 
into the traffic maangement problem.

That's very different from a solution.
I should know; having finally understood that the problem was really 
congestion accountability (back in 2003), it was really tough to find 
a way to actually do it.

Bob