Re: [re-ECN] "Is a standard required?"

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

Do you mean LEDBAT instead of ALTO?

----- Original Message -----
From: re-ecn-bounces@ietf.org <re-ecn-bounces@ietf.org>
To: Stewart Bryant <stbryant@cisco.com>
Cc: re-ecn@ietf.org <re-ecn@ietf.org>
Sent: Thu Apr 29 06:29:34 2010
Subject: [re-ECN] "Is a standard required?"

Stewart Bryant <stbryant@cisco.com> wrote:
> ["David Harrington" <ietfdbh@comcast.net> wrote:]
> 
>> 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?"

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

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

   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.

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

   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.

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

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

--
John Leslie <john@jlc.net>
_______________________________________________
re-ECN mailing list
re-ECN@ietf.org
https://www.ietf.org/mailman/listinfo/re-ecn