Subject: Re: [T2TRG] draft-montenegro-httpbis-h2ot-00 question

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Jul 2016 00:16:56 +0200

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

Gabriel Montenegro wrote:
> One unresolved issue is called out in the security considerations section: one of *the* IoT ciphersuites (TLS_PSK_WITH_AES_128_CCM_8) is disallowed explicitly by HTTP/2:

Indeed.

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.

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.

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;
-- support for UDP, which is both simpler and often more robust;
-- notifications about resource changes (RFC 7641 "Observe").

Obviously, for the $50 IoT (more so the $1000 IoT) the first point can
be less important.

UDP support provides more robustness in networks designed to connect
sensors and actuators; in the legacy InterNAT, actually TCP can be more
robust (for that reason, we are even defining CoAP-over-TCP as we speak).

I'd really like to focus on the third point.  CoAP has extended REST
with notifications, as it is natural for a resource exposing a sensor
value to change.  But REST spans all three protocols, and so should such
an extension.  Well, maybe HTTP/1.1 is too difficult, but HTTP/2 has a
lot of mechanisms already in place to facilitate this.  Maybe we can
find a common model for these that CoAP can then also extend into as
appropriate; clearly RFC 7641 "Observe" is just a start.

Grüße, Carsten

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 14 Jul 2016 07:47:36 +0000

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

Thanks, Carsten! Yes, t2trg, please look this document over.
 
> 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.

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

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