Re: HTTP/2 and Constrained Devices

On Mon, Aug 04, 2014 at 10:05:42PM +0000, Simpson, Robby (GE Energy Management) wrote:
> On 8/4/14, 5:39 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
> 
> My key concern is not the default, but rather the minimum, when it comes
> to MAX_FRAME_SIZE.  I can handle the compromise that the default may be
> large and constrained devices may need to deal and then lower it. But with
> a minimum of 16K, I fear that a lot of devices may simply be unable to
> ever participate (at least reliably).

If one sets compression state size to 0 and disables push (in case of
constrained client), then all frames that don't have a small fixed upper
bound for size can be internally split into smaller subframes.

One then gets pretty much all the problems with CONTINUATION, but one must
be prepared to get those anyway (unless that part of the spec turns out not
to work in practice).

Compression state size of 0 makes compression stateless, so one can just
reset any streams where header decompression fails.

The reason MAX_FRAME_SIZE exists is not that endpoints can't handle 16MB
frames with minimal resources, it is to limit the degree bad endpoints can
screw interactivity by sending overly large frames (not that it is even
useful if using TLS, excluding for HEADERS and PUSH_PROMISE).

> >Well header table is going to be a major source of pain for
> >constrained devices, hence my mention of it.
> 
> I agree, but at least it can be lowered, unless I am missing something.

Yes, it can be forced to 0 for both directions (receving side using
SETTING(SETTINGS_HEADER_TABLE_SIZE=0), sending side using 0x20 HPACK opcode
(header table size update, Max size = 0)).

> How does one have byte alignment without 'E'?
> 
> [Pad Length (8)] + Stream Dependency (31) + [Weight (8)] is my read.

Presumably if the E wasn't there, it would be reserved bit.


-Ilari

Received on Tuesday, 5 August 2014 06:22:50 UTC