Re: [re-ECN] Conex charter - now in External Review

[John Leslie <[e-mail]>]

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

David Harrington <[e-mail]> wrote:
> 
> 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?

   The level of activity on this list would satisfy me.

> is there an adequate community interest that is willing to commit to
> do the work?

   The level of activity on this list would satisfy me.

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

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

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

   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
> be?

   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.

> is the IETF the right place to do the work, or would another
> 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.

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

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

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

   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.

> "Is a standard required because there are multiple vendors getting
> demand from multiple operators for this type of solution to the stated
> problem?"

   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.

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

   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.

> This raises the questions of whether a standard is required, and
> 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.

--
John Leslie <[e-mail]>