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

[Eliot Lear <[e-mail]>]

Hi Martin,

Thanks for your response.  Pelase see below.


On 1/10/17 3:04 PM, Martin Thomson wrote:
> 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.

It's your document.  Decide what you want with it.

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

It is important to state why those factors are important.  It is not
necessary to list every possible one.  Choose wisely so that your points
are illustrated.  Don't hide that information in an Appendix.

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

The jury is still out on how well H2 will succeed.[1]  We can say it has
been very well adopted in a particular use case.  Because IoT is a broad
term, I have no doubt but that H2 will be appropriate in some cases. 
Just because the code is in APIs does not mean it will be used.  It is
unlikely to be appropriate in many cases for numerous reasons, not the
least of which is its code complexity as compared to http/1.1 and CoAP,
and the other being that there is more crypto work needed in closed
systems (maybe ANIMA BrSKI will help with that).

However, none of this was really my point.  My point was really more
about how demand and use of http/1.1 has evolved.  5218 makes the point
that http/1.1 was wildly successful.  See the figure in section 1.2.1. 
That means that it has been broadly adopted well beyond its intended
design space.  But now we see peeling away of some of those uses to
other protocols, such as h2 and CoAP.  How then do we evaluate what is
left?  Are all uses left beyond the design space?  That is what I meant
by “just wild”.   My point is that a careful analysis of that would be
good follow-on work from 5218.  One question is simply this: how does
wild success evolve over time?  Showing a certain amount of continuity
in the board's work seems to me a good thing, and it seems to me that
the document starts down that path, but is somewhat unfocused with its
examples.  Again, that they are in the appendix is indicative of that.

You may find that an analysis such as what I described informs this
work, because there are two questions that leads to: [1] when is “just
wild” aspect a bad thing?  [2] When it is bad, what if any guidance does
the board have to eliminate it?  If it's not a bad thing, then how much
managing of the tail is really necessary when use cases differ?  And
that brings me back to the example I mentioned: HDTV.  In that case
managing the tail was deemed very important because one key incentive
was being able to redeploy the old frequencies.  When do we care about
that on the Internet and what incentives do we have to leverage?

Regards,
[1] https://w3techs.com/technologies/details/ce-http2/all/all