We have two things called "frame"

[martinthomson]

The transport protocol has frames, and STREAM frames can contain frames for the HTTP mapping. It's confusing. We should work out how to deal with that.

[MikeBishop]

I've been trying to consistently say "a QUIC " in the HTTP draft if I refer to a non-HTTP frame. Is that editorial convention sufficient, or were you actually looking to change terms here?

[martinthomson]

Picking another name "segment", "chunk", "lump", "whatsit", would be superior, but that's a good working solution.

[mnot]

H2 already has frames; maybe the new thing should have the new name. E.g., 'QUIC segments".

YMMV.

[mcmanus]

I don't like quic-segments because 1] it implies an ordering (and seqno) and the quic-frames aren't really ordered unless they are streams 2] the term doesn't line up well with tcp segments (which are 1:1 with unfragmented IP).. and quic and tcp are at the same 'layer' - so confusion. The best (but still imperfect) solution I have is to change http frame to http record. It overlaps with TLS of course (which isn't all that desirable), but it uses the term pretty much the same way - to provide delimiters within a QUIC stream. The other idea I had was "http-control-segments".. I think segment is a better fit here as compared against renaming all quic frames to quic segments (again ordering and offset are present) and it emphasizes the native integration between hq and quic for data but not control. I'm not especially concerned that we would be changing the h2-frame language.. HQ doesn't need framing in many of the same places that H2 did so a change in nomenclature is ok to avoid confusion with the transport.

…

On Fri, Apr 28, 2017 at 12:48 AM, Mark Nottingham ***@***.***> wrote: H2 already has frames; maybe the new thing should have the new name. E.g., 'QUIC segments". YMMV. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#128 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAP5s58K4M7rtBP3eMwmWWZ3xo2n5V4Nks5r0W-RgaJpZM4LcZBd> .

[ekr]

Other colors for this bikeshed: Records Blocks Chunks Packets Datagrams On Fri, Apr 28, 2017 at 6:23 AM, Patrick McManus <notifications@github.com> wrote:

…

I don't like quic-segments because 1] it implies an ordering (and seqno) and the quic-frames aren't really ordered unless they are streams 2] the term doesn't line up well with tcp segments (which are 1:1 with unfragmented IP).. and quic and tcp are at the same 'layer' - so confusion. The best (but still imperfect) solution I have is to change http frame to http record. It overlaps with TLS of course (which isn't all that desirable), but it uses the term pretty much the same way - to provide delimiters within a QUIC stream. The other idea I had was "http-control-segments".. I think segment is a better fit here as compared against renaming all quic frames to quic segments (again ordering and offset are present) and it emphasizes the native integration between hq and quic for data but not control. I'm not especially concerned that we would be changing the h2-frame language.. HQ doesn't need framing in many of the same places that H2 did so a change in nomenclature is ok to avoid confusion with the transport. On Fri, Apr 28, 2017 at 12:48 AM, Mark Nottingham < ***@***.***> wrote: > H2 already has frames; maybe the new thing should have the new name. E.g., > 'QUIC segments". > > YMMV. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#128 (comment) >, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ AAP5s58K4M7rtBP3eMwmWWZ3xo2n5V4Nks5r0W-RgaJpZM4LcZBd> > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#128 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD1oZmoCxfsXLB4lnrTwYU6KKpVw65nks5r0ehCgaJpZM4LcZBd> .

[LPardue]

A colleague of mine suggested vesicle...

[ekr]

Also:

Cell
Fragment

[janaiyengar]

Why does the HTTP document need to talk about QUIC frames? Those are QUIC-internal, and HTTP only needs to refer to QUIC streams, right? QUIC itself doesn't encounter HTTP frames, so QUIC never refers to other protocol frames. I think it's fine to reuse frames and streams for the key reason that no matter what you choose (unless you choose "vesicle"), you're likely to conflict with some app. "Stream" is even harder, since video/audio might use it in completely different ways than QUIC, but it's important to note that the scoping is different. ("A video frame can be mapped to a QUIC stream, and a video stream is made up of video frames.") I've always found qualifiers ("QUIC", "HTTP", "video") to be adequate.

…

On Fri, Apr 28, 2017 at 7:47 AM, ekr ***@***.***> wrote: Also: Cell Fragment — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#128 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKjg1F_P_0akyepGz7bVe5ULdU_tQYa_ks5r0fv3gaJpZM4LcZBd> .

[MikeBishop]

We might be able to get out of HTTP referencing QUIC frames, but that’s just wording. The frames represent events which occur. We currently reference: * On the wire, data is framed into QUIC STREAM frames, but this framing is invisible to the HTTP framing layer. A QUIC receiver buffers and orders received STREAM frames, exposing the data contained within as a reliable byte stream to the application. * (Discussing CONNECT) All QUIC STREAM frames on the message data stream correspond to data sent on the TCP connection. Any QUIC STREAM frame sent by the client is transmitted by the proxy to the TCP server; data received from the TCP server is written to the data stream by the proxy. Note that the size and number of TCP segments is not guaranteed to map predictably to the size and number of QUIC STREAM frames. * The following error codes are defined by HTTP for use in QUIC RST_STREAM, GOAWAY, and CONNECTION_CLOSE frames. This doesn’t actually bother me much, because I already have to compare/contrast with HTTP/2 frames. If they’re HTTP/QUIC frames, I just call them <X> frame. If they’re something else, I call them <protocol> <X> frames.

[MikeBishop]

The above solution has proven to be sufficient for now. Though if anyone wants to make a case for QUIC vesicles, feel free to reopen.

[LPardue]

As someone that has written an I-D that needs to reference both QUIC Transport and HTTP documents, I have struggled with ensuring the correct frame-type is being referenced in text.

I have so far used the convention < X > <[ QUIC | HTTP/2 ]> frame. Changing the order is not problematic. I think there would be benefit in defining a consistent style, this can help both readers and writers of specifications. I would propose this to be added at as a section somewhere in a core document.

Furthermore, I recently took the position that HTTP/2 is the wrong term when talking about HTTP/QUIC frames. I will address this, should I call them HTTP/QUIC or would the abbreviation HQ frame also be ok? I would propose that the convention is defined in the HTTP mapping document.

[MikeBishop]

I agree with you on that position, and one of my first editorial changes to the draft was to excise all occurrences of the term "HTTP/2 over QUIC." HTTP/2 and HTTP/QUIC are not the same protocol. Just as h2 is the ALPN token and a convenient shorthand for HTTP/2, hq (or HQ) is a perfectly reasonable shorthand for HTTP/QUIC. I tend to write it out in anything official, mostly to avoid anyone thinking I'm talking about headquarters.

I'm fine adding protocol frame naming to our notational conventions. Reopening to track that suggestion.

[LPardue]

SGTM, thanks Mike.