Subject: #540 jumbo frame, was: Stuck in a train -- reading HTTP/2 draft.

From: <[email-masked]>
Date: Tue, 24 Jun 2014 15:47:36 +0000

Added this as issue #540: https://github.com/http2/http2-spec/issues/540

-keith

On Monday,23 June 2014 17:55, [email-masked] wrote:
+1... especially if it means getting rid of CONTINUATION.

On Mon, Jun 23, 2014 at 5:36 AM, Matthew Kerwin <[email-masked]> wrote:
> On 23/06/2014, [email-masked] <[email-masked]> wrote:
>> On Sunday,22 June 2014 14:36, [email-masked] wrote:
>>> , Matthew Kerwin writes:
>>>
>>>>I realise I should probably clarify my thoughts on what to do if a
>>>>single header doesn't fit in a 16K frame.  The option I like best
>>>>comes from one of PHK's earlier posts, where one of the reserved
>>>>bits in the frame header is used as a "jumbo frame" marker such that
>>>>if it's set the first, say, four octets of payload space is actually
>>>>an extra 32 bits of payload length
>>>
>>> I would have it be the max length of *any* frame we're willing to
>>> accept, and the default would then obviously be the 16kbyte
>>> currently implicit in the standard.
>>>
>>
>> So are you proposing the "jumbo frame" marker for all frames, not
>> just the HEADERS frames?
>
> I suppose so. It makes no sense on a fixed-length frame like PING, but
> it simplifies the machinery no end if all frames have the same
> handling -- that's the whole idea, in fact.
>
>> I think it's a great idea, but I know it makes a bunch of people
>> nervous about HOL blocking if you allow more than 16K in a DATA
>> frame.
>>
>
> Hence the setting.
>
> --
>   Matthew Kerwin
>   http://matthew.kerwin.net.au/
>

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 24 Jun 2014 18:43:22 +0200

I like the concept of jumbo frames.

If we are to get rid of CONTINUATIONS, then a single
SETTINGS_MAX_FRAME_SIZE may not sufficient to replicate what we currently
have.  Currently headers + continuations are unlimited in combined size,
while data frames do have a fixed limit.

So we might need to have a separate settings for HEADERs, with an unlimited
possibility if we are to replicate exactly what we have.   Personally I
think that end points should declare the maximum header size they are
prepared to handle as I doubt there are truly unlimited impls out there.

I also think that the window update should be enhanced to include the
ability to increase the allowed frame size for a stream.   This would allow
a client that has started receiving a download to note that a) it is large;
b) there are no outstanding requests for other resources; c) there are no
outstanding push promises; hence it can make the decision to increase frame
size for the stream without a immediate problem of HOL blocking.  Of course
new requests can always arrive, but the endpoint can make a determination
about a balance between HOL risk and efficient data transfer.

If the client really goofs and increases the frame size to be too large,
then it can always open another connection if a new request turns up and
there is no expectation of an imminent finish to the large frame being
received.

Jumbo frames removes the complexity of CONTINUATION at the cost of the
jumbo frame mechanism, which is probably not a lot simpler.  However it is
easier to describe and understand.  It is equally simple for impls to
ignore if they wish to not support large frames, however there is added
incentive for impls to support it because it does support a mode for
efficient large downloads.

Note that it does not allow headers to be flow controlled - so it is not a
perfect solution to all the issues raised about headers.

cheers

On 24 June 2014 17:47, <[email-masked]> wrote:

> This email message is intended only for the use of the named recipient.
> Information contained in this email message and its attachments may be
> privileged, confidential and protected from disclosure. If you are not the
> intended recipient, please do not read, copy, use or disclose this
> communication to others. Also please notify the sender by replying to this
> message and then delete it from your system.
>

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: <[email-masked]>
Date: Tue, 24 Jun 2014 18:48:34 +0000

On 24 June 2014 18:43, [email-masked] wrote:
> If we are to get rid of CONTINUATIONS, then a single SETTINGS_MAX_FRAME_SIZE may not sufficient to
> replicate what we currently have.  Currently headers + continuations are unlimited in combined size, while data
> frames do have a fixed limit.
> So we might need to have a separate settings for HEADERs, with an unlimited possibility if we are to replicate
> exactly what we have.   Personally I think that end points should declare the maximum header size they are

If you want truly unlimited headers, the only way to do it is with something like CONTINUATION or multiple consecutive HEADER frames.  Otherwise, how would you express the length of a single "unlimited" jumbo HEADER frame that exceeds the max jumbo frame size 2^N-1, where N is the number of bits used to represent the length of a jumbo frame (e.g. 46 bits as Matthew proposed)?

If people really think that 2^46-1 isn't large enough for a single payload (HEADER or DATA), then I suggest an ASN.1 style encoding of the length: If the "jumbo frame" bit is set, the length field represents the number of bytes at the beginning of the payload that represent the actual length.

e.g.

!jumbo; length=0x0005 // jumbo bit NOT set; payload length = 5 bytes
... payload ...                // 5 bytes of payload

jumbo; length=0x0005 // jumbo bit set; # of length bytes = 5
0xff 0xff 0xff 0xff 0xff   // (remaining) payload length = 2^40-1
... payload ...               // 2^40-1 bytes of payload

Nobody can convince me that they need more than 2^14-1 bytes to express the *length* of a single payload. In other words, 2^((2^14-1)*8)-1 bytes of payload.

(In this case, the setting SETTINGS_MAX_FRAME_SIZE would have to mean the max number of bytes allowed to represent the length of a jumbo frame, where 0 means jumbo frames are not allowed.)

> I also think that the window update should be enhanced to include the ability to increase the allowed frame size
> for a stream.   This would allow a client that has started receiving a download to note that a) it is large; b)
> there are no outstanding requests for other resources; c) there are no outstanding push promises; hence it can
> make the decision to increase frame size for the stream without a immediate problem of HOL blocking.  Of
> course new requests can always arrive, but the endpoint can make a determination about a balance between
> HOL risk and efficient data transfer.
>
> If the client really goofs and increases the frame size to be too large, then it can always open another
> connection if a new request turns up and there is no expectation of an imminent finish to the large frame being
> received.
>
> Jumbo frames removes the complexity of CONTINUATION at the cost of the jumbo frame mechanism, which is
> probably not a lot simpler.  However it is easier to describe and understand.  It is equally simple for impls to
> ignore if they wish to not support large frames, however there is added incentive for impls to support it
> because it does support a mode for efficient large downloads.

I bet jumbo frames are a whole lot less error prone than CONTINUATION frames and having END_STREAM on frames that don't actually end the stream.

> Note that it does not allow headers to be flow controlled - so it is not a perfect solution to all the issues raised
> about headers.

Why not (meaning, why can't they be flow controlled)?

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 24 Jun 2014 21:17:59 +0200

On 24 June 2014 20:48, <[email-masked]> wrote:

>
> > Note that it does not allow headers to be flow controlled - so it is not
> a perfect solution to all the issues raised
> > about headers.
>

Because you only know how much of the available window will be consumed by
the send  after you have have encoded the header frame.  Once you have
encoded it with hpack, then you have to send it, so the mutations to the
shared state table will not correctly applied and subsequent encoded frames
can be decoded.

You can't even calculate the encoded size without actually mutating the
table, because the table changes during encoding.  Also the eventual size
when encoded may (and often will be) significantly different depending on
the state of the table after the compression of other frames.

Once encoded with hpack, a frame must be sent, so you cannot apply flow
control to it, without controlling the flow of all headers.

The only solution is to either not have delta encoding (a big loss) or to
not have a single and/or mutable state table.

cheers

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 24 Jun 2014 20:06:52 +0000

In message <[email-masked]>, K
[email-masked] writes:

>I bet jumbo frames are a whole lot less error prone than CONTINUATION frames
>and having END_STREAM on frames that don't actually end the stream.

Not to mention much more efficient because you don't need as many
system calls to send or receive the same amount of data.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.