Re: HTTP/2 and Constrained Devices

On 2014Ė08Ė05, at 10:20 PM, Simpson, Robby (GE Energy Management) <> wrote:

> Currently, the minimum allowed MAX_FRAME_SIZE is 2^14 (16K). For
> constrained devices with ~10KB of RAM (RFC 7228), this effectively means a
> maximum-sized frame can not be held in its entirety in RAM.

Note that HTTP/2 frames have no application-level meaning. The frames received are not the same frames that are sent; only the byte payloads are significant. There should be no more reason to attempt to buffer an entire frame than to attempt to buffer an entire message body in HTTP/1.1. (Message body lengths are unbounded.)

Getting a message body which you need to buffer, but cannot, is improved in HTTP/2 vs. HTTP/1.1 and HTTP/2. In HTTP/1.1 you would have to reset the connection, but in HTTP/2 you can reset only the offending stream.

> To my knowledge, the current IETF-imposed maximum on constrained devices
> is the IPv6 minimum MTU of 1280 octets, and some constrained devices
> struggle there.  But I would suggest somewhere around here for the minimum
> allowed MAX_FRAME_SIZE.

Itís relevant for IP only when it supports datagram protocols. HTTP/2 is not a datagram protocol.

> AFAIK, HTTP/1.1 did not have any frame size limitations on the low end.

HTTP/1.1 didnít have any frames. HTTP/2 clients should not expose frames to the application layer, but only fully demultiplexed streams. HTTP/1.1 didnít have multiplexing either.

A highly constrained machine (only a few kilobytes free) probably wonít support multiple streams at all, and it should set SETTINGS_MAX_CONCURRENT_STREAMS = 1 and then simply strip frame boundaries. Doing anything more with frames known to be on a single stream would be, in fact, an error.

A constrained embedded system would benefit from unlimited-size frames by the reduced frame header overhead. There is no possible downside for a conforming implementation.

> I realize that for the vast majority of web browsing and serving endpoints
> out there, these numbers are quite strange.  However, I'd ask the WG to at
> least consider this to help enable the use of HTTP/2 for IoT applications.
> Or, let me know if I'm missing something or if there is some tradeoff
> that is unbearable.

I think youíre not the first embedded engineer to see a framing layer and expect datagrams. The RFC perhaps should clarify this point.

Received on Tuesday, 5 August 2014 14:46:25 UTC