- From: Simpson, Robby (GE Energy Management) <robby.simpson@ge.com>
- Date: Tue, 5 Aug 2014 14:20:17 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 8/4/14, 6:31 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote: >On 4 August 2014 15:05, Simpson, Robby (GE Energy Management) ><robby.simpson@ge.com> wrote: >> Was the number based on the average response size or something? Some of >> those fun heavy tail measurements? > >The number was based on experience with SPDY. I'm not sure that >anyone shared the exact process by which this number was selected. I >recall it being the smallest size that people could tolerate when we >discussed it at some meeting (which all blur into one, I'm afraid). >There has been no suggestion that the default be reduced further. > >A minimum of 256 was floated, but without a great deal of support. I'll not suggest to change the default, but I am suggesting that the minimum be lowered. 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. 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. AFAIK, HTTP/1.1 did not have any frame size limitations on the low end. 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.
Received on Tuesday, 5 August 2014 14:20:45 UTC