- From: David Krauss <potswa@gmail.com>
- Date: Tue, 5 Aug 2014 22:45:42 +0800
- To: "Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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. > 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