Subject: [re-ECN] status of CONEX

From: Lars Eggert <[email-masked]>
Date: Fri, 5 Feb 2010 09:13:24 +0200

Hi,

on yesterday's telechat, the IESG discussed CONEX and whether the charter should go for external review. My decision after this discussion is to not take that step at this time. My summary of the main objections follows. 

There was hesitation to continue with the chartering process of a working group without knowing a bit more precisely what the outcome would look like and that there is any real interest to deploy it.

Not knowing what the outcome would look like seemed to argue to some that it should be an IRTF research effort and not a WG. It was also not clear if CONEX is an attempt to standardize Re-ECN without saying so, and if not, again the concern was that it was unclear what the outcome would be.

As for deployment, some ADs polled their contacts at a few ISPs, which signaled strong resistance against any sort of congestion-pricing-based solution or at least Re-ECN. (It did not help the proposal that one of those with that opinion was a person from BT...)

In general, I personally had the feeling that the charter wasn't self-contained enough for people to simply read it, understand the problem and the proposed solution angle and feel like they had all the information to confidently state an opinion. (This isn't surprising - this is a complex topic that has proven extremely difficult to boil down into a short piece of text.)

So where do we go from here?

I personally still believe that the IETF should start an activity in this space, but it seems clear that we need to become more concrete in what it is that we want to work on, why it makes sense for us to work on it and that there is an active interest from the folks who will need to implement & deploy the outcome. The IESG discussion yesterday made it clear that reading the current problem statement (draft-tschofenig-conex-ps) and the proposed charter wasn't sufficient for folks to feel convinced about this effort.

CONEX currently has a slot in Anaheim, and I intend to use it for a second BOF to discuss how we would go about this. Leslie & Phil have volunteered to co-chair the BOF - thank you! 

My feeling is that before we can revisit the chartering question, we need a much better self-contained problem description, motivation for why exposing congestion is the desired solution angle and at least an outline about exactly which pieces of information we're planning to expose/share and in which way.

Lars

---

From: ken carlberg <[email-masked]>
Date: Fri, 5 Feb 2010 04:31:51 -0500

Lars,

> As for deployment, some ADs polled their contacts at a few ISPs, which signaled strong resistance against any sort of congestion-pricing-based solution or at least Re-ECN. (It did not help the prop…

was this "strong resistance" based on a concern that upstream transits deploying CONEX would adversely affect the service of downstream transits?  Or was the "strong resistance" rooted in ISP personnel indicating that they would not want to use congestion-priced-based solution within their own network?  

if its the latter, then that seems odd because they can simply the old mantra of "let the market decide" and choose not to deploy it.  If its the former, then that too seems odd given as you say "not knowing what the outcome would look like".

-ken

---

From: ken carlberg <[email-masked]>
Date: Fri, 5 Feb 2010 04:41:18 -0500

On Feb 5, 2010, at 4:31 AM, ken carlberg wrote:

> if its the latter, then that seems odd because they can simply the old mantra of "let the market decide" and choose not

mea culpa, I meant to say "...simply follow the old mantra..."

sorry to clutter up your inboxes.

-ken

> to deploy it.  If its the former, then that too seems odd given as you say "not knowing what the outcome would look like".
> 
> -ken
> 
> 
> 
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn

---

From: Lars Eggert <[email-masked]>
Date: Fri, 5 Feb 2010 11:53:43 +0200

> was this "strong resistance" based on a concern that upstream transits deploying CONEX would adversely affect the service of downstream transits?  Or was the "strong resistance" rooted in ISP perso…

The latter.

> if its the latter, then that seems odd because they can simply the old mantra of "let the market decide" and choose not to deploy it.  If its the former, then that too seems odd given as you say "n…

In order for there to be a market, there needs to be some level of interest from the implementors and ISPs. It was questioned during the discussion if we have that level of interest.

Lars

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 5 Feb 2010 13:06:50 +0100

Hi,

I have the feeling the problem is that there is a misunterstanding that re-ECN or a similar protocol will automatically lead to a congestion-based pricing. I really dont know how to cut this link. Maybe we have to motivate stronger what other purpose ConEx could be used for...?

Btw. there is another problem statement: 
draft-moncaster-congestion-exposure-problem-03
Did the people notice that one?

BR,
Mirja

On Friday 05 February 2010 10:53:43 Lars Eggert wrote:
> >> As for deployment, some ADs polled their contacts at a few ISPs, which
> >> signaled strong resistance against any sort of congestion-pricing-based
> >> solution or at least Re-ECN. (It did not help the proposal that one of
> >> those with that opinion was a person from BT...)
> >
> > was this "strong resistance" based on a concern that upstream transits
> > deploying CONEX would adversely affect the service of downstream
> > transits?  Or was the "strong resistance" rooted in ISP personnel
> > indicating that they would not want to use congestion-priced-based
> > solution within their own network?
>
> The latter.
>
> > if its the latter, then that seems odd because they can simply the old
> > mantra of "let the market decide" and choose not to deploy it.  If its
> > the former, then that too seems odd given as you say "not knowing what
> > the outcome would look like".
>
> In order for there to be a market, there needs to be some level of interest
> from the implementors and ISPs. It was questioned during the discussion if
> we have that level of interest.
>
> Lars

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

web: www.ikr.uni-stuttgart.de
email: [email-masked]
tel: +49(0)711/685-67973
-------------------------------------------------------------------

---

From: Lars Eggert <[email-masked]>
Date: Fri, 5 Feb 2010 14:17:55 +0200

> Did the people notice that one?

Probably not, because it doesn't have the magic "conex" string in the name...

Lars

---

From: ken carlberg <[email-masked]>
Date: Fri, 5 Feb 2010 07:27:16 -0500

> In order for there to be a market, there needs to be some level of interest from the implementors and ISPs. It was questioned during the discussion if we have that level of interest.

thanks for the clarification.

I quite agree in terms of an interest needed by implementors.  But with respect to ISPs (and in particular, those that emerge from traditional carriers), its been my experience that they tend to be the most conservative group of folks concerning *publicly* stated positions.  Hence, I'd be less inclined to focus on their current disposition of a potential capability versus an implementors interest in thinking ahead.  as for a negative reaction from one BT person, I'm sure I can choose several subjects and get two or more positions from different engineers from the same company.

and just to be clear, I'm not advocating complete dismissal of an ISP's position in this particular topic, I'm just saying it needs to be understood under the proper context.  And I would definitely advocate the default position of letting the market decide once your other concerns from your previous note have been addressed

cheers,

-ken

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 05 Feb 2010 13:21:15 +0000

Lars,

The term 'congestion pricing' is an awful way to describe the goals 
of ConEx. For many it evokes the proposal from the late 1990s: 
charging a dynamic price for ECN markings. If anyone in an ISP were 
polled by IESG members out of the blue with "Do you want the IETF to 
work on a protocol for congestion pricing?" I would hope and expect 
they would say a big "No".

Was that really the phrase used to summarise the goals of ConEx?

The whole reason we developed re-ECN was so ISPs could keep existing 
flat price contracts - but choose to add to their acceptable use 
policy (AUP) a clearly specified limit on the user's contribution to 
congestion. Thus giving the *option* of a much more healthy 
alternative than using DPI or volume limits etc.

If this is the level of discussion, how do you suggest we move beyond that?

I understand we can't expect a survey of ISP people to see the 
benefit of something that cannot currently be done with IP - 
especially not in the space of an email poll. But how do we get to a 
position where we can demonstrate the benefits for real?

Bob

At 09:53 05/02/2010, Lars Eggert wrote:
> >> As for deployment, some ADs polled their contacts at a few ISPs, 
> which signaled strong resistance against any sort of 
> congestion-pricing-based solution or at least Re-ECN. (It did not 
> help the proposal that one of those with that opinion was a person from BT...)
> >
> > was this "strong resistance" based on a concern that upstream 
> transits deploying CONEX would adversely affect the service of 
> downstream transits?  Or was the "strong resistance" rooted in ISP 
> personnel indicating that they would not want to use 
> congestion-priced-based solution within their own network?
>
>The latter.
>
> > if its the latter, then that seems odd because they can simply 
> the old mantra of "let the market decide" and choose not to deploy 
> it.  If its the former, then that too seems odd given as you say 
> "not knowing what the outcome would look like".
>
>In order for there to be a market, there needs to be some level of 
>interest from the implementors and ISPs. It was questioned during 
>the discussion if we have that level of interest.
>
>Lars
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 05 Feb 2010 13:37:21 +0000

Lars,

>Probably not, because it doesn't have the magic "conex" string in the name...

A lot of the consensus forming on the list was focused on getting the 
text right in draft-moncaster-congestion-exposure-problem-03, which 
is why it went through 4 drafts.

 From memory, there was little discussion about 
draft-tschofenig-conex-ps-01. I'm not saying the goal of this one 
wasn't laudible: to focus on one just use of ConEx: how it might be 
used by ISPs to handle p2p traffic (although I felt it was important 
to widen this to traffic in general, not just p2p). But I don't think 
the list expected it to be read to the exclusion of the other.

Before Anaheim we'll have to make sure each one refers to the other, 
and what the intended audience of each is.

Bob

---

From: Jason Livingood <[email-masked]>
Date: Fri, 05 Feb 2010 08:37:33 -0500

As an implementer/ISP, we¹ve had folks involved in Conex thus far and
supportive of its mission generally.  My own personal view is that
congestion feedback of some sort to be specified by the IETF is a useful
technical capability separate and distinct from any decision to charge for
it in some unknown manner.  As such I submit it is important to focus on the
technical aspects here and not any business implications/mechanisms, as I
think Bob Briscoe just said in his email a moment ago.

In addition, the subject matter of Conex is quite complex and it seemed to
me that there was some difficulty in the BoF for at least some attendees to
fully comprehend this complex subject in a sort period of time (and I¹m
happy to include myself in that group).  As such, I think it could be time
well spend to continue to explore and tighten the problem statement, and
deliverables, though it certainly appears there is worthwhile work to do
here.

Jason

On 2/5/10 7:06 AM, "Mirja Kuehlewind"
<[email-masked]> wrote:
> 
> I have the feeling the problem is that there is a misunterstanding that re-ECN
> or a similar protocol will automatically lead to a congestion-based pricing. I
> really dont know how to cut this link. Maybe we have to motivate stronger what
> other purpose ConEx could be used for...?

---

From: Lars Eggert <[email-masked]>
Date: Fri, 5 Feb 2010 15:42:33 +0200

Hi,

On 2010-2-5, at 15:21, Bob Briscoe wrote:
> The term 'congestion pricing' is an awful way to describe the goals of ConEx.
(...)
> Was that really the phrase used to summarise the goals of ConEx?

don't get hung up on the terms. The discussion did only touch the economic angle very briefly. This was just me trying to find a name for the broader concept for the purposes fo the email.

> If this is the level of discussion, how do you suggest we move beyond that?

The key issue seems to have been that we need to become more concrete in what it is that we want to work on, why it makes sense for us to work on it and that there is an active interest from the folks who will need to implement & deploy the outcome.

I've now pointed folks at the ID that Mirja reminded me of and asked if that addresses some of the concerns that were raised. 

> position where we can demonstrate the benefits for real?

The issue isn't an ISP poll or demonstrating benefits. The main issue seems to have been what I summarized above. You can blame some of this on the IESG not being fully present in the room when the BOF was held, and so some of us may be lacking all the context, but the scope, goal and planned outcome of a new effort should be understandable to folks who haven't been paying close attention avery step along the way.

Lars

---

From: Matt Mathis <[email-masked]>
Date: Fri, 5 Feb 2010 10:05:17 -0500

So here is a proposal: narrow the scope to just "a mechanism by which
end systems can signal the total congestion that they are experiencing
to the entire path"

Part 1, loss based signalling, is as simple as "Set bit 48 (aka the
evil bit) on all non-retransmissions, clear it on all
retransmissions."  This is a tiny change that can be implemented
unilaterally in the sending end-systems only.    It requires zero
changes in the network or receivers, and is easy to deploy in all
protocols, but is not robust against fraud in some environments, such
as when encryption is in use.  There are some open issues, such as the
treatment of unreliable protocols (never set bit 48?).

Part 2, ECN based signalling, would be robust against fraud, but
requires careful coding design (which is not complete).   As currently
envisioned it would be compatible with RFC 2481 ECN router behavior
and does not require other changes to the network, except perhaps as a
consequence of clarifying correct tunnel behaviors.  The primary
design issues only effect the end systems, and although we do not want
to rule out some small tweak to router behaviors, the WG will
carefully weigh the deployment costs of such changes.

This feels almost too easy....

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://staff.psc.edu/mathis
Work:412.268.3319   Home/Cell:412.654.7529
-------------------------------------------

---

From: Matt Mathis <[email-masked]>
Date: Fri, 5 Feb 2010 11:28:05 -0500

-iesg

Sorry to derail a good process conversation with technical details....

A key way in which my proposal simplifies re-ecn, is to have
eliminated any capability to negotiate Re-Feedback.   This works
because it is self signaled and fails-safe - devices that strip bit 48
are no worse than non-deployment.

Here is another piece for part 2 below: use the same IP layer
encodings and signalling as RFC3168  (ECN-Nonce), except rather than
randomly sending ECT(0) and ECT(1), send ECT(1) for all packets that
raise flight_size to a new maximum (RE-ECN's "green" packets) and
ECT(0) for all others (unmarked, ECN capable).   Then over the life of
a connection count(green) is it the connections maximum window size,
which might actually be useful to the network (since it provides AQM
with a clue about how much a congestion mark will change the load).

Also, except for one little detail, under non-fraud it will be true
that: count(Red)<=count(green)+count(black) where red means
ECNfield==11, Green means ECNfield==01, and black means Bit48==0.  The
problem case comes from current ECN behavior changing green marks to
red marks, which is sure to happen when slowstart causes congestion.
We would like to be able to see both green and red marks on the same
packets.

But slowstart may have a problem anyhow: the 3 bit counter in the TCP
layer to carry the return information in the ACKs may be insufficient
to deal with slowstart on a modern global network (100mb/s*200ms/1500
bytes is likely to experience more than 1000 losses or ECN marks when
coming out of slowsart. Yes all modern stacks can easily cope with
loss at this scale).  If the return path looses too many ACKs, then
count(black) is likely to be wrong.

But I think both of these problems can be overcome.

Thanks,
--MM--

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 05 Feb 2010 18:40:29 +0000

Matt,

I'm replying to both your posts at once (and pasting them the other 
way up, so they read through in order)...

On Fri, Feb 5, 2010 at 10:05 AM, Matt Mathis <[email-masked]> wrote:
 > retransmissions."

I'd suggest the other way round: Clear on non-retransmit; Set on 
retransmit. Otherwise, at the network layer, retransmits look 
identical to traffic in non-ConEx flows, requiring the network to do 
per-flow counting.

 > This is a tiny change that can be implemented

Unreliable protocols would be fairly easy if they have some form of 
feedback (e.g. RTCP or DCCP-TFRC). We would just need to say "Set the 
evil bit for as many subsequent packets as the feedback reports say 
were dropped."
[Or for variable size packets, strictly we should say "for as many 
bytes".] We'd probably pace out the evil marks.

Again, this is only a change at the sender.

Let's call this 'evil-on-drop'.

 > envisioned it would be compatible with RFC 2481 ECN router behavior
[Bob: I assume you mean 3168]
 > carefully weigh the deployment costs of such changes.

I'm not sure whether you mean do Pt 1 first, then Pt 2 later. That 
will introduce an extra incremental deployment step, then we may not 
be able to use any of the Pt1 codepoints for Pt2. I think it gets messy.

I'd argue for designing Pt1 & Pt2 together and only splitting them if 
we can work out incremental deployment between them.

 > This feels almost too easy....

I agree.

I don't think the protocol is the problem, it's the difficulty 
explaining the requirement: why we get deeper into a mess unless we do ConEx.

more...

At 16:28 05/02/2010, Matt Mathis wrote:
>eliminated any capability to negotiate Re-Feedback.

Actually, a re-ECN sender just starts by using what is effectively 
your Pt 1 scheme on the first packet (but with the codepoints the 
other way round - 'evil-on-drop'). It doesn't need to do capability 
negotiation.

The capability negotiation in the re-ECN draft is basically just a 
copy of ECN negotiation. The sender uses this to decide whether to 
shift to your Pt2 (re-ECN). If the receiver doesn't support ECN, the 
sender turns off Pt2 (re-ECN) from the second packet onwards. That 
was the step I got wrong. I didn't think that it could still continue 
to do Pt1 - 'evil-on-drop'. I like your idea a lot now.

[Actually, we did squeeze an extra codepoint into those used for ECN 
negotiation, so a TCP receiver that understood the new codepoint 
could say how much ECN-CE it had seen, rather than just whether it 
had seen at least one ECN-CE in the last RTT. We fitted this all into 
the same bits used for ECN negotiation.]

In summary:
* I think your Pt 1 idea is really cool (if codepoints are reversed), 
and I believe it's dead easy to do.
* It would be fairly trivial to write a draft to specify both your Pt 
1 & Pt 2.
* The transports have to do capability negotiation before they do 
ECN. We basically borrow the same negotiation as ECN to decide 
whether to do pt 2.

>This works

This is true for pt1 & pt2.

Devices that *drop* bit 48 will require detection of no-response and 
fall-back to non-ConEx.

>Here is another piece for part 2 below [now above]: use the same IP layer

I don't like this idea. This requires the network to assume/know the 
transport behaviour is TCP. There's no reason to assume ConEx should 
only be used with TCP, esp. given TCP is well-known to be running out 
of scaling power.

>We would like to be able to see both green and red marks on the same

Again, I think the motivation for this is too tied to TCP behaviour?

>count(black) is likely to be wrong.

I agree the 3-bit counter (in the re-ECN draft) might become too 
small. But anyhow, we (prob in the IRTF) will have to find ways to 
avoid 1000's of losses when coming out of slow-start, as this can 
kill other traffic (e.g. video/VoIP). I've been having ideas how to 
solve slowstart overshoot recently, but not solid enough to shout about yet.

>But I think both of these problems can be overcome.

Agreed.

Bob

---

From: Tina TSOU <[email-masked]>
Date: Sun, 07 Feb 2010 20:05:18 +0800

Hi Bob,
I know P2P traffic goes across backbone networks and metro networks in  
China. Is it also the case in the Europe and North America?
Just questions. I support CONEX though.

B. R.
Tina
http://tinatsou.weebly.com/contact.html

On Feb 5, 2010, at 9:37 PM, Bob Briscoe wrote:

> A lot of the consensus forming on the list was focused on getting  
> the text right in draft-moncaster-congestion-exposure-problem-03,  
> which is why it went through 4 drafts.
>
> From memory, there was little discussion about draft-tschofenig- 
> conex-ps-01. I'm not saying the goal of this one wasn't laudible: to  
> focus on one just use of ConEx: how it might be used by ISPs to  
> handle p2p traffic (although I felt it was important to widen this  
> to traffic in general, not just p2p). But I don't think the list  
> expected it to be read to the exclusion of the other.
>

---

From: Matt Mathis <[email-masked]>
Date: Sun, 7 Feb 2010 22:17:22 -0500

My flippant comment about process vs technology actually obscured an
important feature of my proposal: my real goal was something that
could be explained to non-transport people in two sentences:  "a
mechanism by which end systems can signal the total congestion that
they are experiencing to the entire path" and "...set (clear?) bit 48
on retransmissions...".

On Fri, Feb 5, 2010 at 1:40 PM, Bob Briscoe <[email-masked]> wrote:

> I'd suggest the other way round: Clear on non-retransmit; Set on retransmit.
> Otherwise, at the network layer, retransmits look identical to traffic in
> non-ConEx flows, requiring the network to do per-flow counting.

This doesn't work either, because the network needs independent
marking for ECN capable (controls marking vs drops) and RE-Feedback
enabled (enables congestion based accounting and policy).  All four
combinations will be the common case for some subset of the flows,
depending on features present in the end systems and network.   There
are no possible 3168 compatible markings to mean "ECN disabled,
RE-feedback enabled, except to set bit 48".

Using bit 48 to mean "RE-feedback marked non-retransmit" (as I
suggested), implies that by default non-RE-Feedback enabled traffic is
treated as though it is a retransmission and therefore possibly
subject to policy, which is at least the right sign, although perhaps
too harsh for the unmarked traffic.  Treating non-RE-Feedback and
retransmissions differently only requires that the network remember if
it saw bit 48 on some recent packet for this flow.

> Let's call this 'evil-on-drop'.

No, not drop, your proposal would be "evil-on-retransmission".   and
you are inverted.  :-)

> I'm not sure whether you mean do Pt 1 first, then Pt 2 later. That will
> introduce an extra incremental deployment step, then we may not be able to
> use any of the Pt1 codepoints for Pt2. I think it gets messy.

Well as I said earlier, there isn't any way to use the ECN bits to
signal RE-Feedback capability, so we may as well just agree that ECN
and RE-Feedback are orthogonal, and can't share coding.  There needs
to be independent markings to signal each capability (and if enabled
to indicate marks).

> The capability negotiation in the re-ECN draft is basically just a copy of
> ECN negotiation. The sender uses this to decide whether to shift to your Pt2
> (re-ECN). If the receiver doesn't support ECN, the sender turns off Pt2
> (re-ECN) from the second packet onwards.

This doesn't work at all.  If ECN negotiation failed because the
receiver can't ECN then the sender MUST set both ECN bits to zero,
because otherwise the network will mark ECN instead of drop, and you
have broken congestion control.

> transport behaviour is TCP. There's no reason to assume ConEx should only be
> used with TCP, esp. given TCP is well-known to be running out of scaling
> power.

This is not TCP specific at all.  Although flight_size is defined in a
TCP specific RFC, the concept is general and applies to all protocols.
 Think of it this way: Consider a full RE-ECN implementation, with two
devices in the path: the first one can mark (e.g. a router) and the
second counts (e.g. a policer).  Suppose you have a running flow with
no marks (except that both ECN and RE are enabled).  Suddenly the
router starts ECN (red) marking 100% of the packets.  How many red
marks will the policer see, before the first possible RE (black) mark?
 The answer is the flight_size: the number of packets (and ACKs) in
flight in the network.

>> problem case comes from current ECN behavior changing green marks toto

Nope, To prevent cheating, the policer wants to assure that the total
number of black marks is more than the total number of red marks, but
since the black marks are delayed by one RTT, it needs to give the
black counter a one RTT head start, ergo it needs flight_size of green
marks.  It is precisely correct to set a green mark on every packet
that raises the maximum flight_size, over the entire life of the
connection.   This has nothing to do with TCP.  (It even works for
rate based protocols.  The flight size is the offset between the send
sequence number associated with the most recent received ACK, and the
packet currently being sent).

> Bob

I'm not going to argue about staged deployment (doing my part 1 first)
until we have accomplished step zero: finding an IETF venue to do the
work.  The immediate problem is selling the IESG on a working group.

Thanks,
--MM--
-------------------------------------------
Matt Mathis     http://staff.psc.edu/mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 08 Feb 2010 07:47:07 +0000

Tina,

>China. Is it also the case in the Europe and North America?

Yup - but the most costly part of the network is usually the backhaul 
(sometimes called the regional network or aggregation network in 
other countries) and the access. Wide geographic dispersion, so lots 
of links & interfaces, none of which can be particularly large.

Just to be clear, we shouldn't need to worry about whether it's p2p 
or not. The purpose of ConEx is to move the choice of what is 
important to the end-systems, so whether it's p2p or not won't be of 
concern to the network.

>Just questions. I support CONEX though.

Ta

Bob

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 08 Feb 2010 07:23:59 -0500

So, an important distinction -- 
draft-moncaster-congestion-exposure-problem provoked a lot of good 
discussion on this list, and perhaps even some consensus-forming, but is 
not itself a consensus position at this time.

I read our task at this point to be:  concisely represent the problem 
and state of interest and support for the congestion exposure work. 
Your reporting of the IESG reaction sounds like they had a perfectly 
rational reaction to something they'd thought about for rather fewer 
minutes than are currently necessary to digest existing materials.

Leslie.

Bob Briscoe wrote:
> text right in draft-moncaster-congestion-exposure-problem-03, which is 
> why it went through 4 drafts.
> 
> draft-tschofenig-conex-ps-01. I'm not saying the goal of this one wasn't 
> laudible: to focus on one just use of ConEx: how it might be used by 
> ISPs to handle p2p traffic (although I felt it was important to widen 
> this to traffic in general, not just p2p). But I don't think the list 
> Before Anaheim we'll have to make sure each one refers to the other, and 
> what the intended audience of each is.
> 
> 
> 
> Bob
> 
> 
>> Lars
>>

-- 

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