HTTP/2 and Constrained Devices

I would very much like to see HTTP/2 be useful in constrained devices /
embedded applications.  I believe it to be unfortunate that there is
currently a position to bifurcate the "human web" and the "machine web"
(e.g., HTTP/1.1 vs. CoAP).  In my read of -14, I believe (without having
yet implemented) that HTTP/2 is very close to being quite useful to the
constrained devices / IoT world.

Here are a few concerns:

In 4.2, "All implementations MUST be capable of receiving and minimally
processing frames up to 2^14 octets in length, plus the 9 octet frame
header (Section 4.1)."  We could go back and forth on the term "minimally
processing," but a lot of constrained devices are going to have difficulty
buffering frames this large.  Is there a reason we can not lower or remove
this requirement?

In 5.2.1, "The initial value for the flow control window is 65,535 bytes
for both new streams and the overall connection."  Once again, I believe
constrained devices will have difficulty here.  I realize that for this
case, a new setting can be negotiated, but this could potentially occur
after data have been sent (resulting in a negative window size).  Ideally,
we could also have this be <= to the minimum maximum frame size (2^14).

It would also be helpful to try and maintain byte and/or word alignment in
headers.

Finally, I have not yet studied HPACK, but I do applaud the move away from
deflate.  deflate has terrible memory requirements for constrained devices.

For reference, RFC 7228 has some definitions on "constrained devices."  I
would think ~10 KB RAM and ~100 KB flash would be the most constrained
target.

In addition to discussion on the above, I welcome any thoughts on HTTP/2
and constrained devices.

- Robby


Robby Simpson, PhD
System Architect
GE
Digital Energy

Received on Monday, 4 August 2014 19:47:24 UTC