Re: HTTP/2 and Constrained Devices

On Aug 4, 2014, at 4:39 PM, Martin Thomson <> wrote:

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

There are still some things you can do to deal with large frames:

- Advise low header space (using SETTINGS_MAX_HEADER_LIST_SIZE)
- Tune flow control down limiting the size of data frames
- Support > 4k data frames, but process them in smaller chunks
- REFUSED_STREAM and drain all frames > your internal limit, until you get a SETTINGS ACK
- In the case that clients ignore the header advisory after ACK, REFUSED_STREAM or GOAWAY sending a 431

Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Monday, 4 August 2014 21:59:33 UTC