Re: HTTP/2 and Constrained Devices

Hi David,


Thanks for your thoughtful reply and clarifications.  Some responses
inline below.

On 8/5/14, 10:45 AM, "David Krauss" <potswa@gmail.com> wrote:

>
>On 2014­08­05, at 10:20 PM, Simpson, Robby (GE Energy Management)
><robby.simpson@ge.com> 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.

I agree with the above.  However, in the instance where there is a message
body that one needs to buffer, but cannot, if the frame size could be
limited, then a more thoughtful response (FRAME_SIZE_ERROR) could be sent
rather than simply a reset.  Or a 413 (see below).

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

Agreed. I was merely taking a shot at finding a number.

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

OK, perhaps here is my misunderstanding. If an endpoint received a message
that was smaller than MAX_FRAME_SIZE, would it still be valid to send 413
(Request Entity Too Large)?

If so, then I think most of my concerns fall away and then the only
considerations are really around DoS attacks and stream blocking when it
comes to frame sizes.

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

I was more seeing frames and thinking messages (and therefore thinking all
implementations MUST be able to handle messages of at least 16K).  Thanks
for helping me to better understand!

Received on Tuesday, 5 August 2014 15:43:38 UTC