Subject: Re: [re-ECN] FW: New draft Conex charter - for rapid comments please

From: John Leslie <[email-masked]>
Date: Thu, 1 Apr 2010 12:57:23 -0400

Lars Eggert <[email-masked]> wrote:
> 
> Congestion Exposure (CONEX) WG 
> <snip> 
> 
> However, the CONEX WG will initially focus solely on one use case,
> where the end hosts and the network that contains the destination
> end host are CONEX-enabled but other networks are not.

   Any limitation which excludes the network containing the source
end-host strikes me as seriously unwise.

   Keeping state for flows becomes arbitrarily difficult the farther
one gets from the source host. This is even more true in IPv6, where
there is no strong definition of how many bits of the IPv6 address
are needed to fully specify the end host.

   In practice, only the network containing the source host can know
how many bits are required to uniquely identify a source host, just
as only the network containing the destination host can know how many
bits are required to uniquely identify a destination host.

   Excluding either of these networks from our use case, IMHO, removes
the ability to meaningfully maintain per-flow state.

--
John Leslie <[email-masked]>

---

From: <[email-masked]>
Date: Tue, 6 Apr 2010 10:06:33 +0100

John

Hopefully it wil be clear (in the final version of the charter) that the
main work is on the generative technology. The limited work is on the
use case, as an example of how to use the generative technology. 

I guess the eventual WG would have to discuss in a bit more detail about
the use case work. For example, the destination network is also the
source network in the other direction. The intent (I think!) is
initially not to think hard about the case with lots of networks on the
path, ie where you have to worry about inter-operator trust issues and
changes to the current trust model (currently the 'end' network has a
commercial/trust relationship with the end host).

Anyway, let's see what happens with lars & the iesg. Leslie & I thought
the most important thing was to get a reasonable version into them
whilst the discussion /agreement in Anaheim was still fresh in their
minds. 

Best wishes
Phil/ 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of John Leslie
> Sent: 01 April 2010 17:57
> To: Lars Eggert
> Cc: [email-masked]
> Subject: Re: [re-ECN] FW: New draft Conex charter - for rapid 
> comments please
> 
> 
> > where the end hosts and the network that contains the 
> destination end 
> > host are CONEX-enabled but other networks are not.
> 
>    Any limitation which excludes the network containing the 
> source end-host strikes me as seriously unwise.
> 
>    Keeping state for flows becomes arbitrarily difficult the 
> farther one gets from the source host. This is even more true 
> in IPv6, where there is no strong definition of how many bits 
> of the IPv6 address are needed to fully specify the end host.
> 
>    In practice, only the network containing the source host 
> can know how many bits are required to uniquely identify a 
> source host, just as only the network containing the 
> destination host can know how many bits are required to 
> uniquely identify a destination host.
> 
>    Excluding either of these networks from our use case, 
> IMHO, removes the ability to meaningfully maintain per-flow state.
> 
> --
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn
>

---

From: John Leslie <[email-masked]>
Date: Tue, 6 Apr 2010 15:29:14 -0400

> use case, as an example of how to use the generative technology. 

   I wonder what the reason is to mention a use case at all in the
initial charter...

> the use case work.

    The current proposed charter would seem to disallow that. :^(

> For example, the destination network is also the source network in the
> other direction. The intent (I think!) is initially not to think hard
> about the case with lots of networks on the path, ie where you have to
> worry about inter-operator trust issues and changes to the current
> trust model (currently the 'end' network has a commercial/trust
> relationship with the end host).

   The current trust model is bilateral agreements at each trust
boundary, with no particular assumption about trust being transitive.
I don't believe anyone is proposing a change to that.

   We haven't, of course, settled on a signaling mechanism, but it
seems awfully likely that we'll signal a fractional likelihood of
encountering -- all along the path -- a level of congestion deserving
marking or dropping.

   Our stated goal is to make this fraction visible to all IP forwarders
along the path. (MPLS forwarding is a different issue.)

   So, for starters, a "use case" which forbids any intermediate routers
to be "ConEx enabled" sounds funny...

> Anyway, let's see what happens with Lars & the IESG.

   The IESG Agenda for Thursday contains:

https://datatracker.ietf.org/iesg/agenda/
"... 
" 4.1.1 Proposed for IETF Review
" Area	Date	
" TSV	Jan 19	Congestion Exposure (conex)

and links to a proposed charter including Lars' language
"...
" It is believed that the CONEX mechanism will be useful as a generative
" technology that can be applied as a key element of congestion
" management solutions in a wide variety of use cases. However, the
" CONEX WG will initially focus solely on one use case, where the end
" hosts and the network that contains the destination end host are
" CONEX-enabled but other networks are not.

   The default action by the IESG would be to send this for external
review.

   Perhaps I read this too literally, but it seems to preclude the
sorts of things you're talking about.

   I strongly agree with Bob Briscoe that the "solely" should be
removed. Otherwise, it endangers even discussing use as a generative
technology until we've done all we can with a rather questionable
"use case" and rechartered.

   As for the use case itself, I suggest

s/are not/need not be/

to give
" 
" end hosts and the network that contains the destination end host
" are CONEX-enabled but other networks need not be.

which would at least enable us to discuss what intermediate routers
might do.

> Leslie & I thought the most important thing was to get a reasonable
> version into them whilst the discussion /agreement in Anaheim was
> still fresh in their minds. 

   I wonder how "reasonable" it is to forbid intermediate routers from
being ConEx aware...

   In any case, all this is Lars' call now; but it's unfortunate that
we may be seen as arguing among ourselves _during_ the external review.

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 06 Apr 2010 22:56:13 +0100

Phil, Leslie, Lars,

So can we please agree now to change the charter from:
 > CONEX WG will initially focus solely on one use case, where the end
 > hosts and the network that contains the destination end host are
 > CONEX-enabled but other networks are not.

To:
 > CONEX WG will initially focus on one use case, where the end
 > hosts and the network that contains the destination end host are
 > CONEX-enabled but other networks need not be.

ie:
s/focus solely on/focus on/
s/other networks are not./other networks need not be./

My reading was that even the doubters on the IESG would be happy with 
a use-case that involves ConEx in two neighbouring networks, just as 
long as we:
- preclude MPLS, having ConEx only at IP nodes.
- don't take on more than one use-case.

Bob

>we may be seen as arguing among ourselves _during_ the external review.

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 06 Apr 2010 23:04:44 -0400

> we may be seen as arguing among ourselves _during_ the external review.

Quite honestly -- I think we're tuning at this point, beyond a level at 
which it will make a difference to the external side of reviewing charters.

Yes, it's up to Lars to decide whether he wants to take these 
adjustments on board and put them to the IESG.

Personally, I think dropping "solely" and going to "need not be" are 
reasonable adjustments for the reasons you cite, without becoming 
overambitious in scope.

Leslie.

-- 

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

---

From: Lars Eggert <[email-masked]>
Date: Thu, 8 Apr 2010 13:53:40 +0300

Hi,

it seems that the revised charted that came out of the Anaheim BOF is receiving a more positive IESG reception. I'm including the latest version below, which has some changes requested by IESG members and some changes requested by CONEX folks.

Lars

---

From: John Leslie <[email-masked]>
Date: Tue, 13 Apr 2010 14:48:53 -0400

http://www.ietf.org/mail-archive/web/ietf-announce/current/msg07322.html

(Comments are due by next Tuesday, April 20, and it will likely be on the
IESG Agenda April 22 for approval.)
--
John Leslie <[email-masked]>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 27 Apr 2010 15:21:17 +0100

Is there a list of service providers that have stated that they wish to 
deploy CONEX technology?

Similarly is there a list of service providers that have stated that 
they do not wish to deploy CONEX technology?

Do we know which members of the list that wish to deploy the technology 
need to deploy it over an IP network and which need to deploy it over an 
MPLS enabled network?

Thanks

Stewart

---

From: John Leslie <[email-masked]>
Date: Tue, 27 Apr 2010 11:16:01 -0400

> Is there a list of service providers that have stated that they wish to 

   I am not aware of such a list, although the ISP I own (JLC.net) should
certainly be included.

   In fairness, ConEx is very much a moving target right now, so I'd
hesitate to push any of the ISPs I talk with to plan adoption of it.

> they do not wish to deploy CONEX technology?

   I don't know... this has the same moving-target issue...

   In fairness, I don't think it matters much whether any individual
ISP deploys it. It is about visibility of congestion information, not
about what anyone might do with it. For myself, I always want to stare
at data for a while before attempting to automate anything.

> need to deploy it over an IP network and which need to deploy it over an 

   Good question!

   My personal view is that ConEx makes absolutely no difference except
at IP-layer forwarding points; so I can't imagine why I'd want to view
it (least of all change it) at MPLS layer.

   (I'm only partly familiar with how ECN is carried through MPLS layer
in the EXP field; but I can't think of anything useful to do about it
until the return to IP-layer forwarding.)

> Thanks

   My pleasure...

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 27 Apr 2010 13:47:54 -0400

I agree with John pretty much. Since I have been looking at CONEX, that
would imply that my employer has at least some minimal interest in CONEX
technology. But to make the leap that my employer is committed to deploy
this technology is a huge leap.

Remember: the current charter text states that the current expected work
outputs are "Informational" and "Experimental" documents, so I'm not
even sure what you mean by "deployment".

Here are some (purposely snarky) responses, to show why it is hard to
answer, and why these are BUSINESS QUESTIONS outside of the scope of our
group:

(Let's NOT discuss these questions on the list!!!)

Is there a list of vendors that have stated that they plan to implement
CONEX technology in their products? Is there a list of vendors that have
stated that they have no plans to implement CONEX technology in their
products?

For the vendors that are planning to implement CONEX, what CONEX
features will be implemented? What is the CONEX implementation roadmap?
What is the additional cost for CONEX features (by product, by feature),
or alternatively will certain CONEX features be 'table stakes' for
certain vendors?

Again, let's NOT discuss these questions on the list!!!

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of John Leslie
Sent: Tuesday, April 27, 2010 11:16 AM
To: Stewart Bryant
Cc: [email-masked]
Subject: Re: [re-ECN] Conex charter - now in External Review

> Is there a list of service providers that have stated that they wish
to 

   I am not aware of such a list, although the ISP I own (JLC.net)
should
certainly be included.

   Good question!

   My pleasure...

---

From: ken carlberg <[email-masked]>
Date: Wed, 28 Apr 2010 09:32:02 -0400

> stated that they have no plans to implement CONEX technology in their

I quite agree about not discussing the above questions, or even considering them in any formal manner on this list or IESG discussions.  I sympathize with the curiosity that stems from those questions, but they are quite out of scope of the IETF in chartering WGs.  But if others feel differently, I would like to see how this same litmus test has been conducted in the past for *all* other BoFs, working groups, and even drafts.  Point being -- that's a very nasty rathole to fall into.

cheers,

-ken

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 28 Apr 2010 10:01:52 -0400

> I would like to see how this same litmus test has been conducted in
the past for *all* other BoFs, working groups, and even drafts.  Point
being -- that's a very nasty rathole to fall into.

I *completely* agree.

I have been associated with the DECADE work, which was just chartered
this week. The same questions could have been asked for that work, but
weren't.

-- Rich

-----Original Message-----
From: ken carlberg [mailto:[email-masked]] 
Sent: Wednesday, April 28, 2010 9:32 AM
To: Woundy, Richard
Cc: John Leslie; Stewart Bryant; [email-masked]
Subject: Re: [re-ECN] Conex charter - now in External Review

> stated that they have no plans to implement CONEX technology in their

I quite agree about not discussing the above questions, or even
considering them in any formal manner on this list or IESG discussions.
I sympathize with the curiosity that stems from those questions, but
they are quite out of scope of the IETF in chartering WGs.  But if
others feel differently, I would like to see how this same litmus test
has been conducted in the past for *all* other BoFs, working groups, and
even drafts.  Point being -- that's a very nasty rathole to fall into.

cheers,

-ken

---

From: John Leslie <[email-masked]>
Date: Wed, 28 Apr 2010 11:21:22 -0400

> this week. The same questions could have been asked for that work, but

   If the IESG agreed to charter ConEx last Thursday, we would expect
to have seen that announced no later than yesterday. Thus, the absence
of any such announcement is a strong hint that they haven't yet
agreed to the charter. It is reasonable to assume they're considering
whether some changes to the charter language would help.

   (Or, we could look at the draft agenda for May 6th...)

   In the past, Lars has asked other IESG members to put their concerns
in writing. It is reasonable to assume Stewart is responding to such
a request. Please recall, Stewart is a new IESG member, and may not be
familiar with all the history we would like him to be -- i.e. let's
cut him some slack, please.

   IMHO, the proper answer to his question is, "It doesn't matter."

   Even if every major ISP had committed to _not_ deploy whatever ConEx
may come up with (which is _way_ beyond any possibility I can imagine),
the work is still worth doing for the benefit of enterprises with more
than one upstream path.

   IMHO, the latest proposed charter covers this eventuality nicely
by the sentence:
" 
" However, the CONEX WG will initially focus on one use case, where
" the end hosts and the network that contains the destination end host
" are CONEX-enabled but other networks need not be.

which, IMHO, requires us to come up with something useful for that
case (which, as I read it, excludes _every_ ISP along the way).

   I'm sure many of us have ideas of what intermediate ISPs might do
with the ConEx information in each IP packet -- I've expressed some
of mine on the list -- but these are not appropriate WG issues until
we finish the tasks in the inital charter. Suffice it to say that we
_must_ define ConEx information in a manner which does not depend on
intermediate systems to do anything at all (beyond dropping packets).

   (I also note that Stewart asked about MPLS forwarding: that's a
quite separate question which may deserve more of an answer than
I have already given...)

---

From: ken carlberg <[email-masked]>
Date: Wed, 28 Apr 2010 18:14:08 -0400

> cut him some slack, please.

I quite agree about cutting the fellow a lot of slack.  And I'll respectfully extend my apologies if my earlier response was considered too abrupt....its always hard to convey proper tone over email.

I deeply appreciate Stewart speaking up on the matter on the list.  And whether the proper response to the business oriented questions are "it doesn't matter" or "its out of scope" is possibly splitting hairs.  I just feel strongly that a measure of consistency approach taken by all.

as for the MPLS question, I thought that Bob Briscoe had responded to that question at the Anaheim meeting.  And if so, perhaps he could reiterate it on the list.

cheers,

-ken

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 28 Apr 2010 22:24:47 -0400

> let's cut him some slack, please.

Fair enough... I will cut Stewart some slack as well.

-----Original Message-----
From: ken carlberg [mailto:[email-masked]] 
Sent: Wednesday, April 28, 2010 6:14 PM
To: John Leslie
Cc: Woundy, Richard; Stewart Bryant; [email-masked]
Subject: Re: [re-ECN] Conex charter - now in External Review

> cut him some slack, please.

I quite agree about cutting the fellow a lot of slack.  And I'll
respectfully extend my apologies if my earlier response was considered
too abrupt....its always hard to convey proper tone over email.

I deeply appreciate Stewart speaking up on the matter on the list.  And
whether the proper response to the business oriented questions are "it
doesn't matter" or "its out of scope" is possibly splitting hairs.  I
just feel strongly that a measure of consistency approach taken by all.

as for the MPLS question, I thought that Bob Briscoe had responded to
that question at the Anaheim meeting.  And if so, perhaps he could
reiterate it on the list.

cheers,

-ken

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 28 Apr 2010 23:23:25 -0400

Hi,

This isn't completely responsive to your questions, but I think it helps 
characterize it:  Bob Briscoe compiled this information from this 
mailing list at the time of the first BoF:

2 have implemented
10 promised implementation effort
16 co-authorship
12 contribute effort
14 reviewing
6 protocol design
6 deployment cases
6 trials/testbeds
13 build uses of ConEx
10 analysis/evaluation
23 just support

60% com
40% gov/org/edu

I'd like to highlight something I said in Anaheim:    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.   It does make 
a challenge for determining "deployability".  ISPs will deploy 
solutions, not technology, so "deploy CONEX?" is a very remote and 
challenging question.  And also a very different question than whether 
there is interest and purpose in pursuing it in the IETF.

Leslie.

--

---

From: "David Harrington" <[email-masked]>
Date: Thu, 29 Apr 2010 00:30:42 -0400

Hi,

speaking as the person likely to be the Responsible AD for such a WG
...

Don't put it all on Stewart. 
Stewart raised some points that a number of others have also raised.
Stewart somehow got the job of putting his concerns in writing.

Let me try to increase transparency while we await the issues in
writing.
(These are my impressions, and I'm also a new IESG member, so please
cut me some slack ... ;-)

Are we being fair in asking such questions for CONEX but not all other
BOFs?
I think it fair to say that not all BOFs are asked the same detailed
questions, such as which ISPs have indicated any plans to deploy the
technology.
But it is also fair to say that all BOFs are expected to answer many
of the some basic questions, such as
is there significant community interest?
is there an adequate community interest that is willing to commit to
do the work?
does the significant community interest seem strong enough that it
will last beyond approving a charter? (lots of commitment seems to
evaporate once a charter is approved)
is the problem a real problem?
is the problem well enough understood to actually engineer a solution?
is standardization required to solve the problem?
is there significant community interest in the same direction, or do
people have lots of different ideas about how to solve the problem, so
consensus might be difficult to reach?
is it clear how the technology would be used, and how useful it would
be?
is the IETF the right place to do the work, or would another
organization be more appropriate?
Given the limited resources available (for editing, chairing,
reviewing, directing, etc.) is this the most important work for the
IETF (and the responsible area) to focus on at this time?
and so on ...

I think the biggest questions regarding CONEX so far are:
"Is this at the point where standardization is required, or is this
research?"
"Is a standard required because there are multiple vendors getting
demand from multiple operators for this type of solution to the stated
problem?"

It is not yet clear that multiple vendors are seeing demand for such a
solution, that multiple 
vendors have already implemented a proprietary solution to the problem
in their equipment,
that vendors are at least somewhat likely to implement such a standard
in their equipment, and 
that multiple operators would deploy such a standard if it were
available. 
This raises the questions of whether a standard is required, and
whether IETF is the appropriate place for such work.

I am not authorized to speak for the IESG, but here are my
impressions:
We (the IESG) are paying attention. 
We have asked Stewart to write up his concerns so the mailing list can
respond.
We are soliciting feedback from vendors and operators in the community
so we can assess demand.
We have sent the proposal for External review.
and we continue to discuss it within the IESG.

Some are convinced it should be approved; others are not convinced.
At this point, it is not obvious that it will be chartered.
At this point, it is not obvious that it will not be chartered.
It is under discussion. We have not yet reached rough consensus within
the IESG, and we do not believe the IETF has yet reached rough
consensus on this proposed WG.

Hopefully that gives you some insight into the current status of the
request.
We are working to reach a resolution.

dbh

p.s. if this starts a firestorm telling me how to do my job, or
telling the IESG how to do theirs, then I probably won't bother making
the extra effort for transparency in the future. Fair warning. dbh.

> [mailto:[email-masked]] On Behalf Of Woundy, Richard
> Sent: Wednesday, April 28, 2010 10:25 PM
> To: ken carlberg; John Leslie
> Cc: [email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 29 Apr 2010 09:17:18 +0100

> quite separate question which may deserve more of an answer than
Let me explain why I keep asking about MPLS.

The stated purpose of CONEX is to provide visibility of congestion state 
within the network.

A very large fraction of provider networks use MPLS as their primary 
forwarding mechanism.

In those networks there will only be visibility of the congestion state 
at the network ingress and egress unless an MPLS solution is designed.

If the intent is to design a mechanism that works under the assumption 
that congestion state will normally only be visible at network 
boundaries, then that should be in the charter. If the intent is not to 
make that assumtion, then we should have a very high degree of 
confidence that we can find a viable MPLS solution.

Bob's answer to MPLS in Anaheim was to take it out of scope, but that 
does not address  the central of whether the technology is viable for 
deployment without MPLS support.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 29 Apr 2010 09:38:11 +0100

> demand from multiple operators for this type of solution to the stated
These are the key questions that initiated the search for additional 
information during the review.

Normally you do not need standards unless you are going to get 
multi-vendor deployments in live networks - hence my questions to the 
list about who was likely to deploy and in which type of network.

I am not for a moment suggesting that the IxTF should not do the IPv6 
experimental demonstration of the use of the technology,  but the 
question arose as to whether we needed an IETF  WG to do that.

If there are  IANA policy issues associated with the IPv6 codepoints 
needed to run the experiment, we can run a much lighter weight process 
to get experimental codepoints than to set up and manage a WG.

If the experimentally work (which can run a lot faster without the 
overhead of standardization) demonstrates that CONEX technology is an 
economic benefit to providers, or to the owners of enterprise networks, 
re-running the BOF to set up a WG and create a standard will be pushing 
on an open door.

- Stewart

---

From: ken carlberg <[email-masked]>
Date: Thu, 29 Apr 2010 05:32:02 -0400

On Apr 29, 2010, at 4:38 AM, Stewart Bryant wrote:

> These are the key questions that initiated the search for additional information during the review.
> 
> Normally you do not need standards unless you are going to get multi-vendor deployments in live networks - hence my questions to the list about who was likely to deploy and in which type of network.

ok, so here is the problem with this position -- many vendors will not make commitments until a draft is an RFC.  And even then, there are cases where vendors will not reveal their plans until some time after the RFC has been published. And to add to the irony, a number of these instances are when the vendor has been working on the draft.

operators are even more secretive about there plans.  I understand it and and sympathize with it, but its a business/marketing position that remains out of scope of the standards work.

If you wish, we can take this off line and I can cite personal experience over the years with Cisco on these matters.

-ken

---

From: John Leslie <[email-masked]>
Date: Thu, 29 Apr 2010 06:29:34 -0400

Stewart Bryant <[email-masked]> wrote:
> ["David Harrington" <[email-masked]> wrote:]
> 
>> - "Is this at the point where standardization is required, or is this
>>   research?"
>> 
>> - "Is a standard required because there are multiple vendors getting

   (I'll come back to these, but probably in a different post.)

> list about who was likely to deploy and in which type of network.

   Please forgive me, Stewart, but that sounds like a Cisco view. :^(

   IETF is not a plain-vanilla Standards Development Organization.
We do not have vendors as members, so vendor demand is not what
drives our work.

   Instead, we define standards so that customers can ask their
vendors for a feature which is well-enough-defined to be implemented
by the vendors with a high probability that it will interoperate.
It's quite normal for us to design standards that never see
implementation by multiple vendors.

   I can understand how you might see that as wasteful and want to
change it, but I seriously advise that new IESG members _not_ set
out to change the way IETF operates.

> question arose as to whether we needed an IETF  WG to do that.

   This sounds like a reasonable question; but IRTF tends strongly
to be academic in nature, operating under a very different timetable.
Frankly, if we want experimental demonstration on any particular
schedule, IRTF is not the place to send that work.

> to get experimental codepoints than to set up and manage a WG.

   No doubt, such experimental codepoints should be defined regardless.
Please feel free to sponsor an RFC to do so. But the work we envision
does not want "experimental codepoints" -- we want something where
customers can ask vendors to implement a feature.

   In the IPv4 world, there was indeed a need to "back out a failed
experiment without a trace". There is no such need in IPv6: it's
just fine to leave an IPv6 codepoint unused.

> If the experimental work (which can run a lot faster without the 
> overhead of standardization)

   We've already run experiments, near the limit of what can be done
without interoperability among vendors...

> demonstrates that CONEX technology is an economic benefit to
> providers, or to the owners of enterprise networks, 

   I'm not sure how we _could_ demonstrate that -- typically the
economic issues are not addressed by IETF (our mindset _really_
doesn't match well with Harvard Business School).

> re-running the BOF to set up a WG and create a standard will be
> pushing on an open door.

   Among other things, we've already had two BoFs: the obstacles to
holding a third BoF are formidable.

> - Stewart

   Again, thank you for discussing this openly.

   I'd like to point to the ALTO WG, trying to develop a scavenger-
class service. They want to back off especially quickly if there
turns out to be congestion. They "expect" near-zero congestion; and
IMHO a tool allowing them to say so in every packet might help: a
middlebox changing _nothing_ within the packet could recognise
the scavenger-class service and give quicker feedback.

   (This is not intended as a serious proposal to ALTO, but rather
as an example of what could be done given ConEx tools. Without some
way to differentiate scavenger-class, ISPs like Comcast are forced
to treat scavenger-class the same as web-browsing.)

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 29 Apr 2010 12:52:38 +0200

> 
>    Instead, we define standards so that customers can ask 
> their vendors for a feature which is well-enough-defined to 
> be implemented by the vendors with a high probability that it 
> will interoperate.

Yes (but this is not the only condition - that feature should also be in
answer to a real functional need or operational problem in the Internet,
and the solution should be implementable, deployable, and compatible
with the existing deployed technology) 

> implementation by multiple vendors.

Is this true? Beyond going into the discussion of what is 'normal' I
would observe that an RFC that cannot prove the existence of two
independent implementations cannot be advanced from Proposed to Draft. 

>    I can understand how you might see that as wasteful and 
> want to change it, but I seriously advise that new IESG 
> members _not_ set out to change the way IETF operates.
> 

I do not think that the new IESG members are asking questions that were
not asked before. The IETF does not have infinite resources, this is
something that is not that new. 

Dan

---

From: John Leslie <[email-masked]>
Date: Thu, 29 Apr 2010 10:37:33 -0400

Romascanu, Dan (Dan) <[email-masked]> wrote:
> [John Leslie wrote:]

   True... and WGs are quite properly charged to meet those criteria.

> independent implementations cannot be advanced from Proposed to Draft. 

   As we both know, the percentage of RFCs that progress from Proposed
to Draft has been minuscule.

> I do not think that the new IESG members are asking questions that
> were not asked before.

   I have no objection to asking such questions (though I have some
reservations about posing such questions to only an off-list audience).
I meant only to suggest that requiring "satisfactory" answers to
questions about deployment before chartering a WG strikes me as a
change from historical practice.

> The IETF does not have infinite resources, this is something that is
> not that new. 

   I well understand that watching WGs drag on for years without
producing something "implementable, deployable, and compatible with
the existing deployed technology" is discouraging.

   But I would urge you (and all IESG members) not to insist that
it be accomplished _before_ chartering the WG.

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 29 Apr 2010 11:57:32 -0400

>that multiple vendors have already implemented a proprietary solution
to the problem in their equipment

Maybe some other folks on this mailing list know what is implied by
"proprietary solution", but I would like to see a few examples of these,
and see whether we're solving the same problems, e.g. exposing
congestion events vs reprioritizing traffic, etc.

telling the IESG how to do theirs, then I probably won't bother making
the extra effort for transparency in the future.

Your and Stewart's efforts at IESG transparency for the deliberations of
this particular effort are *extremely* helpful. I can't say that enough.

-- Rich

-----Original Message-----
From: David Harrington [mailto:[email-masked]] 
Sent: Thursday, April 29, 2010 12:31 AM
To: Woundy, Richard; 'ken carlberg'; 'John Leslie'
Cc: [email-masked]
Subject: RE: [re-ECN] Conex charter - now in External Review

Hi,

dbh

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 29 Apr 2010 17:17:18 +0100

Stewart,

First, thanks for taking the trouble to state the concerns of the 
IESG and continue engaging in the debate.
Next, inline...

At 09:17 29/04/2010, Stewart Bryant wrote:

>The stated purpose of CONEX is to provide visibility of congestion 
>state within the network.
>
>In those networks there will only be visibility of the congestion 
>state at the network ingress and egress unless an MPLS solution is designed.
>
>If the intent is to design a mechanism that works under the 
>assumption that congestion state will normally only be visible at 
>network boundaries, then that should be in the charter.

I'd agree if you had said "...under the assumption that congestion 
state will normally only be visible at IP nodes, e.g. network boundaries,..."

That's why the charter says "at IP nodes". It'd be wrong to limit 
ourselves only to network boundaries - they aren't the only IP nodes. 
ConEx might be used on every node in a network of IP-enabled RFID 
readers for some use no-one has even thought of yet. We mustn't 
confuse the way many commercial networks are built with all possible 
uses of IP.

Nonetheless you are right in one sense. All known use-cases of ConEx 
info are at trust boundaries (BRAS, GGSN, homegateways, border 
routers etc). But we don't need to say this in the charter, because 
there's no need to preclude use-cases at IP nodes just because they 
aren't trust boundaries.

>If the intent is not to make that assumtion, then we should have a 
>very high degree of confidence that we can find a viable MPLS solution.

ConEx visibility works *over* MPLS, but I agree it doesn't need to be 
visible *at* MPLS nodes.

>Bob's answer to MPLS in Anaheim was to take it out of scope, but 
>that does not address  the central of whether the technology is 
>viable for deployment without MPLS support.

The technology is certainly viable without MPLS support. This really 
is a non-issue. I thought I had made that clear.

Whether you are asking about MPLS support for ECN [RFC5129] *under* 
ConEx or ConEx support *in* MPLS, ConEx is viable without either.

I can explain in more detail if nec. (I can paste diagram & text I 
already have prepared, because it's not as straightforward as the 
above sentence implies, altho it's a good-enough summary).

HTH

Again, thanks for taking the time to consider this carefully.

Bob

---

From: John Leslie <[email-masked]>
Date: Thu, 29 Apr 2010 13:04:31 -0400

Let me take a quick pass at the questions David lists...

> is there significant community interest?

   The level of activity on this list would satisfy me.

> is there an adequate community interest that is willing to commit to

   The level of activity on this list would satisfy me.

> evaporate once a charter is approved)

   Here we have to pay attention to the names posting to this list.
I find that set impressive.

> is the problem a real problem?

   Good Lord, yes! Congestion is making it impossible for TCP to run
at wire speeds. We need visibility of congestion to have any prayer
of fixing that.

> is the problem well enough understood to actually engineer a solution?

   I believe it is... though by "a solution" I only mean how to make
information visible and credible, not how to enforce policies about
it.

> is standardization required to solve the problem?

   Absolutely: the meaning of any encoding of congestion-expected
needs to be standardized. (What to do about it, IMHO, doesn't yet.)

> people have lots of different ideas about how to solve the problem,
> so consensus might be difficult to reach?

   I've seen only the usual dispersion of ideas -- not any my-way-or-
the highway attitudes.

> is it clear how the technology would be used, and how useful it would

   We've seen potential uses in enough detail to satisfy me they're
viable. We have no idea what other uses may arise; and that's good.

> organization be more appropriate?

   This really is a Transport Area issue, needing a uniform definition
of encoding for a (potentially?) wide variety of transports. While
others are suggesting a home in IRTF, I see neither sufficient
academic interest nor any reason to believe we'd get a standard
within a reasonable period. The right time to standardize the encoding
of information like this is early in the evolution of IPv6 transport.

> IETF (and the responsible area) to focus on at this time?

   I wouldn't touch "the most important" with a ten-foot-pole; but
I'll happily argue that it's more important than some of the WGs
we've formed recently...

> "Is this at the point where standardization is required, or is this

   This is beyond the research stage, in that it needs to be explored
in an internet of the scope of the IPv6 internet -- simulations can
not answer the real question of how to use such information -- and
the information needs to be available to "real" end-users.

   Exactly what to do with the information is still somewhat researchy,
but how to gather it needs actual standards work.

> demand from multiple operators for this type of solution to the stated

   No. A standard is required because end-users with different operating
systems need to agree on the meaning of the encoding. By the nature of
the problem, two end-users need to exchange this information, closely
tied to a transport protcol at each end. What may eventually happen
at IP-forwarding points in between is, admittedly, still researchy;
but such research can't happen without a clear definition of the
encoding.

> solution, that multiple vendors have already implemented a proprietary
> solution to the problem in their equipment, that vendors are at least
> somewhat likely to implement such a standard in their equipment, and 

   It would, IMHO, be unwise to wait for proprietary solutions before
we define a standard meaning for congestion-expected encoding.

   Also, the "vendors" with an interest in this are probably not the
traditional hardware vendors. Admittedly, the presence or absence of
ConEx support in Microsoft Operating Systems would make a big
difference; but its absence hardly precludes useful research and
deployment of congestion-aware transports... and Microsoft needs
substantial development time to implement such, with the outcome
awfully iffy if they lack a standard to implement from.

> whether IETF is the appropriate place for such work.

   I hope I've addressed those questions. A rather narrow standard,
covering the encoding and meaning of the information, is needed
IMHO; and the IETF is far the best-prepared to produce that.

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 29 Apr 2010 18:03:13 -0400

Very good question.

In my personal view, I would consider *where* congestion typically
occurs. In a broadband ISP's network (broadband access + regional access
+ backbone + interconnects), my assertion on this mailing list has been
that when congestion occurs, it usually occurs over or close to the last
mile broadband access network (eg over the DOCSIS network, or between
the DSLAM and BRAS, to pick two examples). Congestion happens less
frequently over interconnects between ISPs, and finally in rare
instances congestion occurs over internal links within the ISP's
regional access networks / backbone. So my assertion implies that the
"interesting congestion" occurs at the network boundaries.

To be fair, I can't say that everyone here would agree with that set of
assumptions.

-- Rich

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Thursday, April 29, 2010 4:17 AM
To: John Leslie
Cc: Woundy, Richard; ken carlberg; [email-masked]
Subject: Re: [re-ECN] Conex charter - now in External Review

within the network.

- Stewart

---

From: "Mcdysan, David E" <[email-masked]>
Date: Fri, 30 Apr 2010 08:41:01 -0400

I have been out and have read the posts on this thread. Not intending to
shoot the IESG messenger, but wanted to add my input.

I agree that in general the detailed discussion of whether deployment of
a protocol before it is  standardized is premature. Based upon the
charter description and mailing list discussions, within the service
provider I work for there are those who do and don't want to deploy any
type of congestion control.

IMO, the IESG needs to look at this problem in a broader perspective --
because this is where the IETF can add the most value. What is needed is
a solution that is deployed by not only service provider using their IP
(possibly MPLS in some special cases) vendors, but also operating system
and application vendors. Without all three, IMO, this effort will
experience the same limited deployment fate as other congestion
approaches (e.g., Decbit, FR DE, ATM CLP, ATM ABR, ECN). 

So, in a sense this is a chicken and egg problem, and there is a need to
start somewhere. IMO, the real driver is application level protocols
that can interpret congestion (and other) feedback from service
providers (ledbat is a start here) in a meaningful business sense. The
operating system is also critical because it is the glue that connects
these parts.

Thanks,

Dave

> [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: Tuesday, April 27, 2010 10:21 AM
> To: [email-masked]
> Is there a list of service providers that have stated that 
> they wish to deploy CONEX technology?
> 
> Similarly is there a list of service providers that have 
> stated that they do not wish to deploy CONEX technology?
> 
> Do we know which members of the list that wish to deploy the 
> technology need to deploy it over an IP network and which 
> need to deploy it over an MPLS enabled network?
> 
> Thanks
> 
> Stewart
> 
> 
> 
>