Re: Path forward with stream headers

[Jana Iyengar <[e-mail]>]

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 <[e-mail]> 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 [[e-mail]] on behalf of Jana Iyengar [
> [e-mail]]
> *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 <[e-mail]> 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" <[e-mail]> 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.
>>
>>     -----Original Message-----
>>     From: Roberto Peon [mailto:[e-mail]]
>>     Sent: Wednesday, June 20, 2018 2:03 PM
>>     To: Martin Thomson <[e-mail]
>> <martin.thomson@gmail..com>>
>>     Cc: Mike Bishop <[e-mail]>; QUIC WG <[e-mail]>
>>     Subject: Re: Path forward with stream headers
>>
>>     You're assuming the data isn't self-descriptive in the body.
>>     -=R
>>
>>     On 6/19/18, 5:29 PM, "Martin Thomson" <martin.thomson@gmail..com
>> <[e-mail]>> wrote:
>>
>>         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.
>>
>>
>>
>>
>>