Re: HTTP/2 and Constrained Devices

On 4 August 2014 14:01, Simpson, Robby (GE Energy Management)
<robby.simpson@ge.com> wrote:
> 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.

The simplest thing to do if you care about avoiding the waste is to
not buffer.  I'll note that the default TCP CWND is larger than 4k on
most clients, so you are more or less forced to deal with more than
you can hold.

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

There are, though I doubt that you'd find the reasons compelling :)
Currently, implementations are not obligated to look for the frame
size limit if they don't intend to use more than 16K.  Lower values
would mean that they need to support the setting.

>>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.

Well header table is going to be a major source of pain for
constrained devices, hence my mention of it.

>>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.

Whether E is present is coupled to whether the priority field is
present.  We do have byte alignment, just not word alignment (whatever
that happens to be on your platform [1]).

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

This one is a real problem.  This would have a major impact on our
ability to send requests prior to getting settings.  Those first round
trips are crucial for performance.  The stream flow control window
might be reduced without serious impact, I guess, but I'm sure that
you are most concerned about the connection window.  Note also that
headers don't consume flow control credits.

--Martin

[1] https://en.wikipedia.org/wiki/Word_%28computer_architecture%29#Table_of_word_sizes

Received on Monday, 4 August 2014 21:39:41 UTC