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: Mon, 4 Aug 2014 22:05:42 +0000
To: Martin Thomson <martin.thomson@gmail.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <D005788F.38C0A%Robby.Simpson@GE.com>
On 8/4/14, 5:39 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:

>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
>> can be done to inform the peer to stop sending frames that large.  At
>> 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.

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

Also, as an aside, by "waste" I also worry about transmissions (battery

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

Yea, at least not strongly compelling.   :)

Was the number based on the average response size or something?  Some of
those fun heavy tail measurements?

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

I agree, but at least it can be lowered, unless I am missing something.

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

How does one have byte alignment without 'E'?

[Pad Length (8)] + Stream Dependency (31) + [Weight (8)] is my read.

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


- Robby

Received on Monday, 4 August 2014 22:06:09 UTC

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