Subject: Path forward with stream headers

From: Mike Bishop <[email-masked]>
Date: Tue, 19 Jun 2018 21:22:37 +0000

During the Kista interim, we discussed the Unidirectional Stream Headers proposal (PR #1359).  In the current spec, the first three unidirectional streams have a designated purpose identified by the stream ID; all remaining server-initiated unidirectional streams are used for push, and no other client-initiated unidirectional streams are used.

The proposal is, at the most basic level, to use the first byte of a unidirectional stream to indicate its purpose.

Pros:

  *   Reduces need for application layer to reach into transport and get a particular stream ID; this simplifies initialization and insulates the application from how the transport chooses to manage stream allocation.
  *   Enables extensibility - without this, it is problematic to add a unidirectional stream for any purpose in the future without a protocol rev.  As with QPACK, there are cases where a long-lived stream might be preferable to a series of control-stream frames that need to be correlated together.

Cons:

  *   Streams aren't required to be presented "in order;" in the event of reordering, this makes the remainder of the stream unusable until the first byte has arrived.
  *   Assuming that different stream types get dispatched to different handlers, the stream might exist but not be assignable to a handler until the first byte arrives (different view of previous issue).  This creates a stream object that no one "owns."

Some implementations that have looked at this think the first con is irrelevant (since HTTP/QUIC doesn't make affordances for out-of-order consumption anyway) and the second can be addressed by the use of a "dispatch" handler whose job is to read the first byte and invoke the correct next handler.  This handler would own the stream until the first byte was available.

Following the discussion in Kista, the hum was largely split between "Do this" and "Need more time/info," with only a few "Don't do this" hums.  However, there hasn't been any substantive discussion of the proposal since then.

What does the WG need to move folks from the middle bucket into one of the other two?

---

From: Roberto Peon <[email-masked]>
Date: Tue, 19 Jun 2018 22:08:35 +0000

I think you just kicked the discussion off Mike!

Another thing that was mentioned was to have these as two different stream frames.
One could have both self-describing and ‘this-is-not-special’ streams by taking up a single additional codepoint.

-=R

From: QUIC <[email-masked]> on behalf of Mike Bishop <[email-masked]>
Date: Tuesday, June 19, 2018 at 2:23 PM
To: QUIC WG <[email-masked]>
Subject: Path forward with stream headers

Pros:

  *   Reduces need for application layer to reach into transport and get a particular stream ID; this simplifies initialization and insulates the application from how the transport chooses to manage stream allocation.
  *   Enables extensibility – without this, it is problematic to add a unidirectional stream for any purpose in the future without a protocol rev.  As with QPACK, there are cases where a long-lived stream might be preferable to a series of control-stream frames that need to be correlated together.

Cons:

  *   Streams aren’t required to be presented “in order;” in the event of reordering, this makes the remainder of the stream unusable until the first byte has arrived.
  *   Assuming that different stream types get dispatched to different handlers, the stream might exist but not be assignable to a handler until the first byte arrives (different view of previous issue).  This creates a stream object that no one “owns.”

Some implementations that have looked at this think the first con is irrelevant (since HTTP/QUIC doesn’t make affordances for out-of-order consumption anyway) and the second can be addressed by the use of a “dispatch” handler whose job is to read the first byte and invoke the correct next handler.  This handler would own the stream until the first byte was available.

Following the discussion in Kista, the hum was largely split between “Do this” and “Need more time/info,” with only a few “Don’t do this” hums.  However, there hasn’t been any substantive discussion of the proposal since then.

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 19 Jun 2018 23:22:29 +0000

Considering con 1, in the present design push streams assign special meaning to the push ID variant that appears at the start of the stream. So implementations will be stuck until the first bits are delivered anyway, with or without a type byte.

________________________________________
From: QUIC [[email-masked]] on behalf of Roberto Peon [[email-masked]]
Sent: 19 June 2018 23:08
To: Mike Bishop; QUIC WG
Subject: Re: Path forward with stream headers

-=R

Pros:

Cons:

---

From: Mike Bishop <[email-masked]>
Date: Tue, 19 Jun 2018 23:37:54 +0000

I largely agree with you, Lucas, but will point out that in the current design you at least know that it's a push stream.  So a hypothetical implementation can at least get the stream assigned to its "push handler" even if it can't begin to route the pushed content.  Essentially this adds a second layer of indirection before the stream gets assigned to the final consumer.

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]] 
Sent: Tuesday, June 19, 2018 4:22 PM
To: Roberto Peon <[email-masked]>; Mike Bishop <[email-masked]>; QUIC WG <[email-masked]>
Subject: RE: Path forward with stream headers

Another thing that was mentioned was to have these as two different stream frames.
One could have both self-describing and 'this-is-not-special' streams by taking up a single additional codepoint.

-=R

Pros:

Cons:

---

From: Mike Bishop <[email-masked]>
Date: Tue, 19 Jun 2018 23:40:13 +0000

If you mean QUIC STREAM frames, I’m going to register my strong objections to that.  That’s not a distinction the QUIC transport needs, and I’m hesitant to ask them to add it on HTTP’s behalf.

The other suggestion I heard was having different regions of streams, such as continuing to consume the first three unidirectional streams (without type byte) for the control streams we know will exist, then have a type byte past that point for disambiguating all subsequent streams.

From: Roberto Peon [mailto:[email-masked]]
Sent: Tuesday, June 19, 2018 3:09 PM
To: Mike Bishop <[email-masked]>; QUIC WG <[email-masked]>
Subject: Re: Path forward with stream headers

-=R

From: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of Mike Bishop <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 19, 2018 at 2:23 PM
To: QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Path forward with stream headers

Pros:

Cons:

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Jun 2018 09:47:25 +1000

I don't see any reason to add that for HTTP/QUIC either.  Even if you
get past the type and push ID, there is still the (highly ordered)
HEADERS frame there.  A different protocol might not have this
restriction, but we're talking about a mechanism in the HTTP mapping,
not the generic protocol.

Also, if you are concerned that frames might arrive before the purpose
of a stream is known, send the first octet with every other STREAM
frame until it is acknowledged.  It's a little wasteful, and doesn't
really help much, but it's entirely possible.

I'm pretty strongly in favour of a change here.
On Wed, Jun 20, 2018 at 9:41 AM Mike Bishop <[email-masked]> wrote:
> Reduces need for application layer to reach into transport and get a particular stream ID; this simplifies initialization and insulates the application from how the transport chooses to manage stream allocation.
> Enables extensibility – without this, it is problematic to add a unidirectional stream for any purpose in the future without a protocol rev.  As with QPACK, there are cases where a long-lived stream might be preferable to a series of control-stream frames that need to be correlated together.
>
>
>
> Cons:
>
> Streams aren’t required to be presented “in order;” in the event of reordering, this makes the remainder of the stream unusable until the first byte has arrived.
> Assuming that different stream types get dispatched to different handlers, the stream might exist but not be assignable to a handler until the first byte arrives (different view of previous issue).  This creates a stream object that no one “owns.”
>
>
>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 20 Jun 2018 00:01:58 +0000

There is a misunderstanding here, born of my belief that the frame-types (disassociated from HTTP semantics) we have for HTTP should suffice for basically every protocol (assuming we solve the L7 mapping issue with stream groups or some similar).

I’ll note that even for HTTP, it is possible to send only QPACK literals in a stream, meaning that we will be inducing potential additional HoL blocking in that case. This will not be interesting for most current HTTP implementations, which only deliver bytes in-order, but it seems to me to be a “TCP-is-not-just-sockets” style issue where API and protocol have become conflated.

-=R

From: Mike Bishop <[email-masked]>
Date: Tuesday, June 19, 2018 at 4:40 PM
To: Roberto Peon <[email-masked]>, QUIC WG <[email-masked]>
Subject: RE: Path forward with stream headers

-=R

Pros:

Cons:

---

From: Roberto Peon <[email-masked]>
Date: Wed, 20 Jun 2018 00:21:02 +0000

Another way to attempt to express this:

Imagine an HTTP implementation which has an API which enables data to be interpreted as it is received.
In other words, instead of a socket-like API which returns data only when you've received ALL of the prior N bytes, you get a scatter-gather API which can present data as if you were receiving the results of many range requests. 

This is purely an API change-- you still either send a request and got data, or were server push'd data. 

In the case of mapping video to HTTP, one could separate the "container bits" (a.k.a. framing stream) and elemental bitstream into separate HTTP objects. Thus, if I've received all of the bytes on the framing stream that describe a portion of the elemental bitstream, and I have that portion of the elemental bitstream, I can present video. 
As I know you know, it is often advantageous to give data to the decoder to present video in a timely manner to the user, even when doing so introduces noise.
There are other layouts that would make sense: Putting all I-frames into a separate HTTP object from the one which has all of the P-frames, etc.

This (presentation of a portion of the video) could be possible without receiving any of the bytes of the elemental bitstream for/from the previous GOP, which could have been sent in the prior packet(s).

This could be done with server push as written for HTTP today, assuming the client has APIs exposed to allow it access to the data (as is the starting premise).

However, if one must receive the first packet of each stream, additional HoL blocking (which prevents playback/interpretation) is induced.

-=R 

On 6/19/18, 4:48 PM, "Martin Thomson" <[email-masked]> wrote:

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Jun 2018 10:29:06 +1000

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

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 20 Jun 2018 06:24:11 +0000

As Martin says the first byte isn’t that special. However, the frame might
be delivered with an empty.

More generally in QUIC, it could be useful to have an API guarantee that
the first N bytes delivered to a frame are not fragmented, where N is a
reasonable limit, like 8 bytes and that retransmission does not fragment
that section.

This would not prevent out of order delivery of later frames but it greatly
simplifies adding custom headers to a stream.

A recent change permitted sending empty frame headers without FIN bit,
which I think is fine, but if the application asks for 0..8 bytes to be
atomic, I think that would be useful too. If nothing else as a substitute
for atomic message frames.

On 20 June 2018 at 02.29.32, Martin Thomson ([email-masked])
wrote:

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.

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 20 Jun 2018 09:26:19 +0000

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

>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]>
>> However, if one must receive the first packet of each stream, additional HoL
>blocking (which prevents playback/interpretation) is induced.
>
>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: Patrick McManus <[email-masked]>
Date: Wed, 20 Jun 2018 08:49:06 -0400

I'm sensitive to Roberto's point about in-order being an API property and
not a protocol property. I think hq has a future there.

otoh, the winning argument here seems to be that this only impacts the
first frame of the stream and there is a tendency to put other
stateful/routeful things in there anyhow - so the impact is small for any
reasonably sized stream.. and one message per stream models are probably
getting their out-of-orderness between streams instead of intra-message
anyhow.

so I'm in the pro camp.

---

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

I agree.  This is already a property of using frames.  Just like the video itself consisting of both structure and content, you have to find the frame header (and therefore its length) first.  Once you have that, you can do two things:

  *   Random access anywhere within that frame
  *   Locate the header of the next frame and begin interpreting it, if that’s received first

However, removing blocking on the frame header entirely is a pretty substantial change (and probably looks a lot like HTTP/QUIC -01 or so, with a dedicated stream for data).  I don’t feel like blocking on the first byte is necessarily any different from blocking on the first frame header which immediately follows it.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]]
Sent: Tuesday, June 19, 2018 5:29 PM
To: Roberto Peon <[email-masked]>
Cc: Mike Bishop <[email-masked]>; QUIC WG <[email-masked]>
Subject: Re: Path forward with stream headers

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.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 20 Jun 2018 21:03:07 +0000

You're assuming the data isn't self-descriptive in the body.
-=R

On 6/19/18, 5:29 PM, "Martin Thomson" <[email-masked]> wrote:

---

From: Mike Bishop <[email-masked]>
Date: Wed, 20 Jun 2018 21:48:00 +0000

But you don't know where the body is until you've seen the header.  Otherwise, you're not certain that what you're seeing *is* body, rather than something in a different frame that happens to look like your self-description.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 20 Jun 2018 21:56:06 +0000

Agreed—one must be able to locate and know what data is before one can safely interpret it.

There are two arguments here for ways one could do that:

  1.  There are HTTP (the L7 protocol) usecases where one can interpret data without having received the first portion of the stream.
In a (theoretical QUIC V2) world with stream groups, one would know by virtue of the fact that the stream is in a stream group that the endpoint of the data is the same, and thus be able to infer, or determine by encoding the data in multiple places/offsets/with FEC what those first bytes may have been.
  2.  Non-HTTP usecases which may know about the relationship of streams/stream groups such as WebRTC.

We’re not currently designing for #2, for better or worse.

With the proposal right now, we are forcing HoL blocking for both HTTP and non-HTTP streams by making the assumption that data cannot be interpreted without the first few bytes.

I guess it all comes down to:
   What is the benefit of the proposal that outweighs the potential loss?
and
  What is the cost of burning a codepoint (as a frame-type) to prevent the potential loss?

It seems like the benefit of what we’re doing is to normalize QPACK’s streams with everything else/make QPACK streams+streamIDs not special.
I like the idea of a self-descriptive stream-type-- in particular, I like the idea of the self-descriptive stream-type because it allows a fairly obvious (potential future) mapping of multiple QPACK contexts onto a single connection.
OTOH, I hate that we’d force all HTTP unidirectional streams into it when we can define usecases that would be impacted by that decision.
-=R

From: Mike Bishop <[email-masked]>
Date: Wednesday, June 20, 2018 at 9:32 AM
To: Martin Thomson <[email-masked]>, Roberto Peon <[email-masked]>
Cc: QUIC WG <[email-masked]>
Subject: RE: Path forward with stream headers

---

From: Roberto Peon <[email-masked]>
Date: Wed, 20 Jun 2018 22:05:25 +0000

Yep, you're right, because we're not having HEADERS vs DATA frames as a QUIC-layer thing, we're screwed. 

-=R

On 6/20/18, 2:48 PM, "Mike Bishop" <[email-masked]> wrote:

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 21 Jun 2018 12:37:33 -0700

Mike's point that the HTTP headers need to be read before reading data from
a stream out of order makes it clear that the first bytes are already HoL
blocking in this current mapping. Given the current mapping, while I'm
sympathetic to Roberto's argument that there are use cases where an
application might want to read data out of order from a stream, I don't see
additional HoL blocking because of this byte.

That said, I like the self-descriptiveness of the stream ID. Even for
debugging purposes, it's a matter of training yourself to understand what
stream IDs mean what type of stream, but once that's done, it's always true
for QUICv1. Having looked at a large number of GQUIC traces, I can say that
being able to tell at a glance what a particular stream ID across traces is
very useful (In GQUIC, stream 1 is crypto, stream 3 is headers, and stream
5 is the first request stream from the client).  With a type byte,
debuggability is worse, since you now must see the first byte and remember
what stream ID maps to what for the rest of the connection, and you need to
do this for every connection you're looking at.

Given my experience, I would prefer having stream IDs that are self
descriptive.

I understand the desire to keep this flexible for future tweaks of
HTTP/QUIC without a version rev, but it is a degree of freedom that we can
surely plan to exercise for things we cannot anticipate right now. I'm not
yet convinced that adding this additional extensibility mechanism is
necessary right now.

On Wed, Jun 20, 2018 at 3:05 PM Roberto Peon <[email-masked]> wrote:

>     But you don't know where the body is until you've seen the header.
> Otherwise, you're not certain that what you're seeing *is* body, rather
> than something in a different frame that happens to look like your
> self-description.
>
>         > However, if one must receive the first packet of each stream,
> additional HoL blocking (which prevents playback/interpretation) is induced.
>

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 21 Jun 2018 20:14:14 +0000

Hi Jana,

I appreciate the debuggability concerns, can this just be solved by tooling? Is the issue with trying to look at application debug logs in realtime as applications receive QUIC packets?

Wireshark for HTTP/2 already acts statefully when it decrypts sessions and dissects HPACK, would it be terribly difficult for it to read this first byte and represent the stream type in a convenient way?

Note that the proposal is just for unidirectional streams - client-initiated bidi streams are normal request/response on incrementing stream IDs, that's all that needs to be looked for in a lot of traffic scenarios.

I'm probably far less experienced with debugging GQUIC traces but in my experience cross referencing frames from Stream 3 to the response stream was always a bit clunky, especially for push promise. See the attached screenshot of a very old wireshark dissect of GQUIC (NB Alexis La Goutte quickly fixed the bug with decoding the Header Block Fragment shown in that image, thanks!).

Lucas
________________________________
From: QUIC [[email-masked]] on behalf of Jana Iyengar [[email-masked]]
Sent: 21 June 2018 20:37
To: Roberto Peon
Cc: Martin Thomson; QUIC WG; Mike Bishop
Subject: Re: Path forward with stream headers

Mike's point that the HTTP headers need to be read before reading data from a stream out of order makes it clear that the first bytes are already HoL blocking in this current mapping. Given the current mapping, while I'm sympathetic to Roberto's argument that there are use cases where an application might want to read data out of order from a stream, I don't see additional HoL blocking because of this byte.

That said, I like the self-descriptiveness of the stream ID. Even for debugging purposes, it's a matter of training yourself to understand what stream IDs mean what type of stream, but once that's done, it's always true for QUICv1. Having looked at a large number of GQUIC traces, I can say that being able to tell at a glance what a particular stream ID across traces is very useful (In GQUIC, stream 1 is crypto, stream 3 is headers, and stream 5 is the first request stream from the client).  With a type byte, debuggability is worse, since you now must see the first byte and remember what stream ID maps to what for the rest of the connection, and you need to do this for every connection you're looking at.

Given my experience, I would prefer having stream IDs that are self descriptive.

I understand the desire to keep this flexible for future tweaks of HTTP/QUIC without a version rev, but it is a degree of freedom that we can surely plan to exercise for things we cannot anticipate right now. I'm not yet convinced that adding this additional extensibility mechanism is necessary right now.

On Wed, Jun 20, 2018 at 3:05 PM Roberto Peon <[email-masked]<mailto:[email-masked]>> wrote:
Yep, you're right, because we're not having HEADERS vs DATA frames as a QUIC-layer thing, we're screwed.

-=R

On 6/20/18, 2:48 PM, "Mike Bishop" <[email-masked]<mailto:[email-masked]>> wrote:

    -----Original Message-----
    From: Roberto Peon [mailto:[email-masked]<mailto:[email-masked]>]
    Sent: Wednesday, June 20, 2018 2:03 PM
    To: Martin Thomson <[email-masked]<mailto:martin.thomson@gmail..com>>
    Cc: Mike Bishop <[email-masked]<mailto:[email-masked]>>; QUIC WG <[email-masked]<mailto:[email-masked]>>
    Subject: Re: Path forward with stream headers

    On 6/19/18, 5:29 PM, "Martin Thomson" <martin.thomson@gmail..com<mailto:[email-masked]>> wrote:

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 21 Jun 2018 16:06:31 -0700

Hi Lucas,

It's a matter of training... the tools can certainly help, but my point is
that there is value in specific stream IDs being known identifiers, rather
than opaque identifiers. I find self-descriptiveness to be valuable.

I'm also not yet convinced that we need extensibility in this particular
manner. Are there examples of things we anticipate needing this
extensibility for, that we wouldn't want a version rev for?

- jana

On Thu, Jun 21, 2018 at 1:14 PM Lucas Pardue <[email-masked]> wrote:

> Hi Jana,
>
> I appreciate the debuggability concerns, can this just be solved by
> tooling? Is the issue with trying to look at application debug logs in
> realtime as applications receive QUIC packets?
>
> Wireshark for HTTP/2 already acts statefully when it decrypts sessions and
> dissects HPACK, would it be terribly difficult for it to read this first
> byte and represent the stream type in a convenient way?
>
> Note that the proposal is just for unidirectional streams -
> client-initiated bidi streams are normal request/response on incrementing
> stream IDs, that's all that needs to be looked for in a lot of traffic
> scenarios.
>
> I'm probably far less experienced with debugging GQUIC traces but in my
> experience cross referencing frames from Stream 3 to the response stream
> was always a bit clunky, especially for push promise. See the attached
> screenshot of a very old wireshark dissect of GQUIC (NB Alexis La Goutte
> quickly fixed the bug with decoding the Header Block Fragment shown in that
> image, thanks!).
>
> Lucas
> ------------------------------
> *From:* QUIC [[email-masked]] on behalf of Jana Iyengar [
> [email-masked]]
> *Sent:* 21 June 2018 20:37
> *To:* Roberto Peon
> *Cc:* Martin Thomson; QUIC WG; Mike Bishop
> *Subject:* Re: Path forward with stream headers
>
> Mike's point that the HTTP headers need to be read before reading data
> from a stream out of order makes it clear that the first bytes are already
> HoL blocking in this current mapping. Given the current mapping, while I'm
> application might want to read data out of order from a stream, I don't
> see additional HoL blocking because of this byte.
>
> very useful (In GQUIC, stream 1 is crypto, stream 3 is headers, and
> stream 5 is the first request stream from the client).  With a type byte,
>>     To: Martin Thomson <[email-masked]
>> <martin.thomson@gmail..com>>
>>     On 6/19/18, 5:29 PM, "Martin Thomson" <martin.thomson@gmail..com
>> <[email-masked]>> wrote:
>>

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 21 Jun 2018 23:36:39 +0000

One broad example I think mentioned somewhere once related to HTTP extension frames. In H2, frames not associated with request/response are usually dumped on the control stream. Large, unrelated frames could HoL block that stream.

HTTP/QUIC could allow such frames to be sent on unidirectional streams ( but not currently because server push gobbled up a half of that space).

Lucas
________________________________________
From: Jana Iyengar [[email-masked]]
Sent: 22 June 2018 00:06
To: Lucas Pardue
Cc: Roberto Peon; Martin Thomson; QUIC WG; Mike Bishop
Subject: Re: Path forward with stream headers

Hi Lucas,

It's a matter of training... the tools can certainly help, but my point is that there is value in specific stream IDs being known identifiers, rather than opaque identifiers. I find self-descriptiveness to be valuable.

I'm also not yet convinced that we need extensibility in this particular manner. Are there examples of things we anticipate needing this extensibility for, that we wouldn't want a version rev for?

- jana

On Thu, Jun 21, 2018 at 1:14 PM Lucas Pardue <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jana,

Lucas
________________________________
From: QUIC [[email-masked]<mailto:[email-masked]>] on behalf of Jana Iyengar [[email-masked]<mailto:[email-masked]>]
Sent: 21 June 2018 20:37
To: Roberto Peon
Cc: Martin Thomson; QUIC WG; Mike Bishop
Subject: Re: Path forward with stream headers

-=R