W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: HTTP/2 and Constrained Devices

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>
Message-ID: <D0065CC8.38C8D%Robby.Simpson@GE.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC