RE: draft-montenegro-httpbis-h2ot-00 question

[Gabriel Montenegro <[e-mail]>]

> (CCing T2TRG, whom I'd ask to have a look at the above document.)

Thanks, Carsten! Yes, t2trg, please look this document over.
 
> HTTP/2 has good mechanism for many applications in the IoT (see below
> for some more thoughts).  However, this mechanism is also loaded with
> policy, which only really considers the Big Web/Browser Web today.
> Getting those policies adapted to the little web may be the biggest
> change that is needed, much less so more (or different) mechanism.

That's the premise, yes. A beginning of those policies' changes are discussed in the draft, as HTTP/2 is flexible enough that altering its behavior and resources is not difficult. But I agree that the main job is to adapt HTTP/2 to IoT just like TCP/IP was adapted to the cellular data networks over a decade ago (in the process obsoleting the entire WAP stack). The question is not just about application transport and HTTP/2, it's about an entire stack that, well adapted, could be common and shared between IoT and non-IoT, mainstream scenarios (again, analogous to the fact that phones no longer use WAP but the same tcp/ip protocols and software stacks as one uses on laptops, tablets, servers...). 

Who knows, maybe IoT is definitely different and we need to invent all sorts of new protocols to address it. But judging from history, it may be that a large number of IoT scenarios can use the well-known (but adapted/profiled) stack. At the very least it is worth investigating what this option would look like.

> Not all of the IoT is in the little web, so it's easy to find examples
> where generalities do not apply.  It may also be more instructive to
> think both about the 1 W+, $50 (A-class platforms with Linux) IoT vs.
> the $5 (or $0.50), microcontroller and microwatts IoT.

Yes, our assumption and initial learnings is that http/2 can apply quite well for small IoT devices, but lot more work needs to happen here, I agree. 

> Looking at the three REST transfer protocols, CoAP's niche is among
> other details based on:
> 
> -- several orders of magnitude less complexity for basic cases;

Would be great to see the data for this and how complexity is measured. I think this applies as compared to http/1.x, but much less (if at all) to http/2.

> -- support for UDP, which is both simpler and often more robust;

The part about robust is debatable. Perhaps for some scenarios, but for other equally important ones you end up adding so much stuff that eventually you might as well use TCP. Some folks think that UDP is a must, but then we look at MQTT which is much more widely deployed than CoAP, and it is TCP-only (deployment of UDP version is in the noise from what MQTT people tell me). How to adapt TCP is another question. We've seen that it is a dog that can learn new tricks (e.g., L4S BoF). Perhaps there is a need to build all sorts of functionality on top of UDP. QUIC is doing just that and its first goal is to carry HTTP/2 precisely. It will be interesting to see how that evolves from the point of view of IoT applicability.
 
> -- notifications about resource changes (RFC 7641 "Observe").

HTTP has had long polling for ages to effect this, but it is not efficient. HTTP/2 adds PUSH, which makes this pattern much more efficient.

Thanks,

Gabriel