Re: h2 frame layout

In the spirit of getting less meta....


I've no objections to proposal A, but I don't think it gains much either.

I like the direction that Proposal B goes, ie getting rid of general flags
within the frame header, but there were several optional parts in that
proposal that I think need to be fleshed out.    In general, I'm not that
keen on END_STREAM and END_HEADERS being new frame types as I think the
extra  2*64 bytes for a minimal HTTP message is significant.

So here is a sub-proposal of proposal B where I expand some of the options
that Roy outlined:


*Proposal B0*

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |E|                 Stream Identifier (31)                      |
 +---------------+-----------------------------------------------+
 | Frame Type(8) |   Payload Length (24)                         |
 +=+=============================================================+
 |                   Frame Payload (0...)                      ...
 +---------------------------------------------------------------+

E == END_STREAM

So the currently defined flags would be handled as:

   -   END_STREAM:  using E bit (was the reserved bit)
   -   END_HEADERS: Use END_META_DATA frame (see below)
   -   PADDED: send in padding frame (see other thread)
   -   PRIORITY: send in priority frame (see other thread)
   -   Settings ACK: SETTING_ACK frame type
   -   Ping ACK: PONG frame type.


With this proposal, instead of carrying headers and trailers as

  HEADER CONTINUATION*

We would effectively carry them as

  CONTINUATION* HEADER

ie the different frame type is used to indicate the last frame and not the
first (which
depends on the proposal to move optional priority out of the HEADERS frame).

However, since headers can be sent as trailers, I would optionally propose
that we
rename to END_META_DATA and META_DATA, so a complete HTTP message is

    META_DATA* END_META_DATA DATA* (META_DATA* END_META_DATA)?

For PUSH_PROMISE frames, we would need to remove the header block from the
pp frame itself and instead send in a following frame:

    PUSH_PROMISE META_DATA* END_META_DATA




*Proposal B1*
I think there is merit in generalising the distinction between META_DATA
and END_META_DATA, as if we ever wanted to revive end segment semantics,
it would not really be sufficient to come up with END_DATA and DATA,
because
the semantics of a segment would not be understood by intermediaries

So to generalise further B1 uses 1 bit of the frame type as a generic
END_SEGMENT:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |E|                 Stream Identifier (31)                      |
 +---------------+-----------------------------------------------+
 |S|Frame Type(7)|   Payload Length (24)                         |
 +=+=============================================================+
 |                   Frame Payload (0...)                      ...
 +---------------------------------------------------------------+

E == END_STREAM
S == END_SEGMENT

So the currently defined flags would be handled as:

   -   END_STREAM:  using E bit (was the reserved bit)
   -   END_HEADERS: Use S (see below)
   -   PADDED: send in padding frame (see other thread)
   -   PRIORITY: send in priority frame (see other thread)
   -   Settings ACK: SETTING_ACK frame type
   -   Ping ACK: PONG frame type.

A HTTP message sequence would then become:

    META_DATA+ DATA* META_DATA*

and a push promise:

    PUSH_PROMISE META_DATA+

Note also that strictly speaking an end point need not look at the
END_SEGMENT
flag to extract HTTP semantics, as first DATA frame or END_STREAM indicates
the end of the metadata.  However it is better to require the END_SEGMENT
bit to
be set so that Intermediaries can be written to forward any frame with the
END_SEGMENT flag set in a timely fashion, without having to know about
HTTP semantics.


regards






On 3 September 2014 07:54, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 2 September 2014 14:36, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> > Things like keeping the :headers first, maybe even in strictly
> > defined order like HTTP/1.1 does it will be much more important
> > for high performance implementations.
>
> Yeah, we did that because we could when we removed the reference set
> from HPACK.  A fixed order (or even format, so you avoid the need for
> labels) might have been better in that regard, though it would have
> complicated things a little more.
>
>


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