Re: HTTP/2 and Constrained Devices

Hi Martin,

On 8/4/14, 4:37 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:


>Hi Robby,
>
>The limits that we have, minimum and default, might be difficult for
>severely limited devices, but that is a problem that can be managed by
>streaming.  There is nothing inherent in the protocol that requires
>buffering of an entire block of anything.  For a constrained device
>prior to being able to get settings out, it might be necessary to
>discard frames (c.f. REFUSED_STREAM) to avoid having to commit extra
>resources.

This seems a bit wasteful and could also result in the peer not
understanding the issue.  Let's say I have a constrained device that can
only buffer 4K at a time.  If I receive frames > 4K, there is nothing that
can be done to inform the peer to stop sending frames that large.  At the
end of the day, it seems one must assume the ability to handle a 16K
frame, unless I am missing something.  Granted, I suppose one could use
the TCP receive window, but we have windowing here and I'm guessing that
there will be cases where an entire frame will need to be held before it
can be processed.

In the end, is there a problem with having a minimum < 16K?

>Note that we can't do things like change the header table size without
>affecting other users, like the web, more than we'd like.

Understood.  I'm not suggesting changing the default HEADER_TABLE_SIZE.
And I certainly understand web is the predominant use case.

>As for alignment, I realize that we're not perfect, but the only way
>to get alignment is to pad, and no one has been willing to do that.

My first suggestion is to not make the 'E' bit optional in the HEADERS
Frame Payload.

>>In 5.2.1, "The initial value for the flow control window is 65,535 bytes
>> for both new streams and the overall connection."  Once again, I believe
>> constrained devices will have difficulty here.  I realize that for this
>> case, a new setting can be negotiated, but this could potentially occur
>> after data have been sent (resulting in a negative window size).
>>Ideally,
>> we could also have this be <= to the minimum maximum frame size (2^14).

Is it problematic to have the initial value for the flow control window <=
the minimum maximum frame size (whatever it may be)?

Received on Monday, 4 August 2014 21:01:43 UTC