Subject: PUSH_HEADERS frame

From: Mike Bishop <[email-masked]>
Date: Wed, 20 Jun 2018 16:37:32 +0000

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:[email-masked]] 
Sent: Wednesday, June 20, 2018 2:26 AM
To: Martin Thomson <[email-masked]>; Roberto Peon <[email-masked]>
Cc: QUIC WG <[email-masked]>; Mike Bishop <[email-masked]>
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:[email-masked]] On Behalf Of Martin Thomson
>Sent: 20 June 2018 01:29
>To: Roberto Peon <[email-masked]>
>Cc: QUIC WG <[email-masked]>; Mike Bishop <[email-masked]>
>Subject: Re: Path forward with stream headers
>
>On Wed, Jun 20, 2018 at 10:21 AM Roberto Peon <[email-masked]> 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.
-----------------------------

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 20 Jun 2018 18:27:36 +0000

Thanks for the feedback. To be clear, I'm in favor of typed streams but to play devils advocate. 

> Unidirectional streams aren't required to use HTTP/QUIC frames;

QPACK aside, the only examples we have use frames. So the question is: do we think it is in scope to support un-framed STREAM bytes as an HTTP/QUIC extension point?

Back to PUSH_HEADERS, the change is a subtle one. I'd highlight the Header Block, which presently has two bearer frames HEADERS and PUSH_PROMISE. The main difference with push is that the stream ID cannot be used to correlate request and response. So we use a push ID that is framed everywhere *except* the push delivery stream. PUSH_HEADERS is a more honest approach to this quirk (at some small framing inconvenience), everything relevant to the Header Block is bundled together. It acts as a stream reservation mechanism that ties push response data, with request and response headers.  

It doesn't change much: 

Untyped streams (today): push ID + HEADERS + DATA (+ HEADERS)
Typed streams: stream type byte + push ID + HEADERS + DATA (+ HEADERS)
Untyped and framed streams:  PUSH_HEADERS (including push ID) + DATA (+HEADERS)

I could try to make a weak argument that framing helps because you could at least skip over frames if you get their length but not the rest. The current design requires the full push ID to be received before HEADERS and DATA processing.

Lucas

---

From: Mike Bishop <[email-masked]>
Date: Wed, 20 Jun 2018 18:57:58 +0000

Philosophically, I'd go a step further and say that, as in the PR, the semantics of the stream are entirely determined by the type byte.  Any internal divisions of regions within the bytestream are as needed by that type and defined by it.  Some, like the QPACK stream, won't actually need divided regions.

The fact that push streams and control streams subdivide their regions using frames from the same type space as request streams is somewhere between a convenience due to push's similarity to things we already have (responses) and a historical legacy of H2.  There's no reason they would need to do so; there's just also no real reason to change.

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]] 
Sent: Wednesday, June 20, 2018 11:28 AM
To: Mike Bishop <[email-masked]>; Martin Thomson <[email-masked]>; Roberto Peon <[email-masked]>
Cc: QUIC WG <[email-masked]>
Subject: RE: PUSH_HEADERS frame

It doesn't change much: 

Untyped streams (today): push ID + HEADERS + DATA (+ HEADERS) Typed streams: stream type byte + push ID + HEADERS + DATA (+ HEADERS) Untyped and framed streams:  PUSH_HEADERS (including push ID) + DATA (+HEADERS)

Lucas

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Jun 2018 09:51:36 +1000

I agree with Mike.  FWIW, implementing push is trivial as a result of
it using the same framing as requests and responses; I would be
opposed to changing that.

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 21 Jun 2018 00:30:33 +0000

Well, I only partially buy the simplicity from reusing HEADERS. The client has juggling to do to parse push ID in order to correlate the response with request - I'd argue whether it is done inside or outside the frame equally trivial.

Anecdotally, when explaning HTTP/QUIC server push to an audience not tracking WG progress so closely, it has struck people as quite a departure from H2 and GQUIC (for the better I might add). FWIW I think typed streams would make communication easier, as it makes the capability more conspicuous.

Lucas
________________________________________
From: Martin Thomson [[email-masked]]
Sent: 21 June 2018 00:51
To: Mike Bishop
Cc: Lucas Pardue; Roberto Peon; QUIC WG
Subject: Re: PUSH_HEADERS frame

---

From: Roberto Peon <[email-masked]>
Date: Thu, 21 Jun 2018 17:30:22 +0000

As Mike showed, typed frames and typed streams are very much not the same.
Lucas, are you arguing for typed *frames* or typed *streams*?
-=R

On 6/20/18, 5:31 PM, "Lucas Pardue" <[email-masked]> wrote:

    
    Lucas

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 21 Jun 2018 18:08:33 +0000

I'm arguing against the middle ground we currently have. So either typed streams, or extensions as untyped streams with HTTP framing to support disambiguation.

The downside of mandatory framing is it prevents unexplored use cases.

P.s. Another place to unframed data is the CONNECT method, exchange STREAM frames rather than DATA.

Lucas
________________________________________
From: Roberto Peon [[email-masked]]
Sent: 21 June 2018 18:30
To: Lucas Pardue; Martin Thomson; Mike Bishop
Cc: QUIC WG
Subject: Re: PUSH_HEADERS frame

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