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

On 24 June 2014 18:43, gregw@intalio.com wrote:
> 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.

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


> On 24 June 2014 17:47, <K.Morgan@iaea.org> wrote:
>> Added this as issue #540: https://github.com/http2/http2-spec/issues/540
>> -keith

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.

Received on Tuesday, 24 June 2014 18:49:08 UTC