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

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Jul 2016 10:20:57 +1000

This is an interesting piece.  I certainly hope that this is being
discussed in other venues than just the HTTP working group, in a sense
it's less valuable for us than others.

On the profile section, are there particular aspects to h2 that are
not particularly well-suited to implementation in constrained devices?
 Is there anything that implementing h2 has suggested (that maybe
hasn't already been suggested to this working group?

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 13 Jul 2016 19:16:05 +0000

> it's less valuable for us than others.

Thanks!

Not currently being discussed elsewhere, although we've thought about a couple of groups. Any suggestions? 

The main ideas to encourage HTTP/2 for IoT were presented and discussed a couple of IETF’s ago at a CoRE WG meeting. Even though there were some favorable responses, this group isn’t really chartered to go work on HTTP/2, as they’re very CoAP-centric. The bigger picture is that we should explore a common stack across IoT and other scenarios, so we should not need new WG’s to deal with IoT issues. IoT is the norm and we should get used to it in every working group.

> hasn't already been suggested to this working group?

The focus of the draft is currently on exploring how to use current HTTP/2 for IoT now within the confines of the defined protocol. This is the subject of the profile and implementation sections in the draft. 

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:

   Given the security challenges in IoT scenarios, HTTP/2 is assumed to
   use TLS services.  In Internet scenarios, [RFC7540] has clear
   guidance in this respect.  In Constrained network scenarios, the
   guidance for IoT is [I-D.ietf-dice-profile].  However, these are
   currently at odds.  For example, Section 4.2 of
   [I-D.ietf-dice-profile] mandates the ciphersuite
   TLS_PSK_WITH_AES_128_CCM_8 for preshared key-based authentication
   (quite common in IoT deployments).  On the other hand, Appendix A of
   [RFC7540] includes TLS_PSK_WITH_AES_128_CCM_8 in the HTTP/2 Black
   List of disallowed cipher suites, despite it being an AEAD
   ciphersuite.  This is still to be resolved.  The other IoT
   ciphersuite mandated by [I-D.ietf-dice-profile], namely,
   TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (used for both certificate-based
   and Raw Public Key-based authentication) is not on the HTTP/2 Black
   List.

Or is the intent of your question asking what changes in HTTP/2 would make it more amenable to IoT?  One aspect that could reap benefits would be if binary headers came back into the picture. Also, whereas there is plenty of room to negotiate parameters, it would also help if there were some way for both sides to agree on a given profile without incurring in any negotiation. The draft hints that in practice, prior knowledge can be used to this effect. You might recall that we proposed profile negotiation in ALPN a long time ago (which is where the “h2” and “h2c” tokens actually originated, where h2c meant the “constrained” profile). But this didn’t progress, partly because ALPN tokens lead to explosion. At any rate, prior knowledge has been used in massive scale already to bypass ALPN altogether (Twitter). Whereas the draft doesn’t advocate this, it hints that prior knowledge could be used to bypass parameter negotiation. 

But this is a good question. In part, the purpose of issuing this draft is to ask people to think about this question.

Robby may have further thoughts about this...

Thanks,

Gabriel

---

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

> 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