PUSH_HEADERS frame

[Mike Bishop <[e-mail]>]

Separating threads, because I think this is really a separate topic.

Perhaps I'm missing something, but I don't see how that change substantively changes anything for the better.  Unidirectional streams aren't required to use HTTP/QUIC frames; the QPACK stream certainly don't.  (It actually might make sense to have separate frame type spaces between request streams and control streams, but that's a separate conversation.)  The push stream uses the same frames because it's fundamentally the same thing as a response to a request, so it's encoded the same way.  It's a convenience -- defining a new frame type to support it seems like the wrong direction.

Your proposal would move the Push ID slightly later in the stream, but not otherwise change anything.  While the odds of having intermediate responses on a push are vanishingly low, it's not illegal and neither are trailers.  So now the Push ID is a property of each header block rather than of the stream, and I don't know how to make sense of a stream where they differ between frames.

-----Original Message-----
From: Lucas Pardue [mailto:[e-mail]] 
Sent: Wednesday, June 20, 2018 2:26 AM
To: Martin Thomson <[e-mail]>; Roberto Peon <[e-mail]>
Cc: QUIC WG <[e-mail]>; Mike Bishop <[e-mail]>
Subject: RE: Path forward with stream headers

I agree with Martin. However, to think around the topic a little, the telling problem is that we want two things: a stream with meaning other than bidirectional request/response, and to reuse the frames (HEADERS and DATA) associated with request/response. This leads to having to add the push ID to the unidirectional stream header.

So here's a candidate proposal:

Remove the push ID from the stream header and put it a new PUSH_HEADERS frame (notice the similarity to PUSH_PROMISE):

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Push ID (i)                        ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Header Block (*)                      ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 8: PUSH_HEADERS frame payload

   The payload consists of:

   Push ID:  A variable-length integer that identifies the server push
      that this is a response to.

   Header Block:  QPACK-compressed response headers.
     See [QPACK] for more details.

This shifts the problem of reordering from stream byte position more towards the HTTP Message Exchange sequence defined in 3.2.

Lucas

>-----Original Message-----
>From: QUIC [mailto:[e-mail]] On Behalf Of Martin Thomson
>Sent: 20 June 2018 01:29
>To: Roberto Peon <[e-mail]>
>Cc: QUIC WG <[e-mail]>; Mike Bishop <[e-mail]>
>Subject: Re: Path forward with stream headers
>
>On Wed, Jun 20, 2018 at 10:21 AM Roberto Peon <[e-mail]> wrote:
>> However, if one must receive the first packet of each stream, 
>> additional HoL
>blocking (which prevents playback/interpretation) is induced.
>
>This is the bit I'm pushing back on.  The first byte isn't privileged.
>There's a push ID, a HEADERS frame, and the start of the first DATA 
>frame before you can start into random access.  Without that, you can't 
>know what you are reading.  I fail to see how one additional octet is a problem here.



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
-----------------------------