RE: Path forward with stream headers

[Lucas Pardue <[e-mail]>]

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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>]
    Sent: Wednesday, June 20, 2018 2:03 PM
    To: Martin Thomson <[e-mail]<mailto:martin.thomson@gmail..com>>
    Cc: Mike Bishop <[e-mail]<mailto:[e-mail]>>; QUIC WG <[e-mail]<mailto:[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<mailto:[e-mail]>> wrote:

        On Wed, Jun 20, 2018 at 10:21 AM Roberto Peon <[e-mail]<mailto:[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.