Re: HTTP/2 and Constrained Devices

Hi Robby,

The limits that we have, minimum and default, might be difficult for
severely limited devices, but that is a problem that can be managed by
streaming.  There is nothing inherent in the protocol that requires
buffering of an entire block of anything.  For a constrained device
prior to being able to get settings out, it might be necessary to
discard frames (c.f. REFUSED_STREAM) to avoid having to commit extra
resources.

Note that we can't do things like change the header table size without
affecting other users, like the web, more than we'd like.

As for alignment, I realize that we're not perfect, but the only way
to get alignment is to pad, and no one has been willing to do that.


On 4 August 2014 12:46, Simpson, Robby (GE Energy Management)
<robby.simpson@ge.com> wrote:
> 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 20:38:14 UTC