Re: [arch-d] [IAB] Call for Comment: <draft-iab-protocol-transitions> (Out With the Old and In With the New: Planning for Protocol Transitions)

[Martin Thomson <[e-mail]>]

Hi Eliot,

I'm going to speak for myself and pick on a few points you make, and
let others comment on the things that I am less knowledgeable about.

You ask for more meat on the document in a couple of ways.  I think
that you do raise some relevant questions, and it's probably the case
that the IAB needs to consider the effect of market consolidation.  I
do think that we should avoid burdening this document with a
requirement to address all of those concerns though.

We're learning, particularly as feedback on this document comes in,
that there are lots of great examples of how transitions can be wildly
different.  Based on that, I'm not sure that this document can never
be comprehensive enough to address all possible considerations.  In
fact, I don't see that to be its purpose.  A document that highlights
the importance of considering transition factors is of more benefit
now than a detailed manual that we may never publish (not suggesting
that was your intent, just drawing on the extremes).

On 5 January 2017 at 20:17, Eliot Lear <[e-mail]> wrote:
> HTTP/2 versus HTTP/1.1 goes tot he heart of RFC 5218.  Because HTTP1.1 has
> "enjoyed" wild success, there is an opportunity to revisit that.  For
> instance, is it still enjoying wild success or is it simply now just wild?
> That is, has H2 taken its primary use case, leaving everything other than
> what it was designed to do?  And maybe that's okay.  One could argue that
> the other use cases look a lot like CoAP, and yet CoAP may only cover a
> fraction.

I don't agree with the implied characterization of h2.  It is true
that h2 provides optimizations that are primarily aimed at certain
styles of deployment. Consequently, those deployments are more likely
to spend the effort to analyze the performance trade-offs and deploy
the new code.  You are also (probably) talking about deployments that
tend to move a lot faster.

But h2 is functionally complete as a replacement for HTTP/1.1.  To
suggest that only really big sites, CDNs and major browsers are the
ones that are using h2 is just wrong.  Use of h2 in things like APIs
is pretty widespread now, it's just not as obvious.  Multiplexing
there is a huge win for throughput and efficiency.

We've also seen cogent arguments that insist that h2 is almost
perfectly suited to IoT deployments because of those same
optimizations. Though we're seeing the effect of some of the choices
we made to package changes together: IoT devices generally prefer to
use use weaker crypto than h2 permits.

(Not sure what you are getting at with the "just wild" statement.)