Subject: [quicwg/base-drafts] Ben Kaduk's HTTP/3 Comment 4 (#4779)

From: Lucas Pardue <[email-masked]>
Date: Wed, 20 Jan 2021 11:42:36 -0800

@kaduk said

> Section 9
>
> Is there anything useful to say about whether an HTTP extension might
> want to make use of QUIC frames other than STREAM?  In the spirit of
> greasing, I worry that if we don't say something, "all HTTP/3 frames go
> in QUIC STREAM frames" might become an implicit invariant.  (Yes, I know
> about draft-ietf-quic-datagram.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4779

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 22 Jan 2021 10:07:30 -0800

(as an individual) clarifying that all frames defined in draft-ietf-quic-http3 are sent in QUIC STREAM frames is probably useful. This is couched in the requirement that these H3 frames explicitly depend on reliable and in-order delivery. It might be worth checking we make that clear in the spec.

However, the current requirements are not invariant, we don't want to prohibit H3 extensions from utilizing transport extensions like DATAGRAM, partial reliability, or some future STREAM-frame replacement that might emerge.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4779#issuecomment-765591897

---

From: Mike Bishop <[email-masked]>
Date: Fri, 22 Jan 2021 10:48:52 -0800

The draft currently says:

> A QUIC stream provides reliable in-order delivery of bytes, but makes no
guarantees about order of delivery with regard to bytes on other streams. On the
wire, data is framed into QUIC STREAM frames, but this framing is invisible to
the HTTP framing layer. The transport layer buffers and orders received QUIC
STREAM frames, exposing the data contained within as a reliable byte stream to
the application. Although QUIC permits out-of-order delivery within a stream,
HTTP/3 does not make use of this feature.

This seems sufficient to me.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4779#issuecomment-765615056

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 22 Jan 2021 11:15:27 -0800

The application data abstraction that QUIC offers right now is streams, which is what HTTP/3 uses; the text that @MikeBishop pointed to makes that clear. We could change how data is sent in QUIC from STREAM frames to something entirely different, and that should not matter to HTTP/3 as long as the abstraction is the same: reliable, in-order, byte-stream.

I'm not worried about this mapping becoming an effective invariant for HTTP/3, since (i) changing this contract (say, for datagram webtransport) requires negotiating that change at both HTTP and QUIC levels; and (ii) if we don't deploy extensions that use other mappings between HTTP data and QUIC frames, I don't think saying that we allow other mappings in the future does much.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4779#issuecomment-765628767

---

From: Mike Bishop <[email-masked]>
Date: Fri, 22 Jan 2021 13:31:07 -0800

It's also worth noting that HTTP/3 as currently defined requires exactly QUIC version 1.  Permitting additional QUIC versions will require an update or a follow-on spec which can adapt to any changed abstractions at the same time.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4779#issuecomment-765696454

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 25 Jan 2021 10:43:39 -0800

I guess my point is that the text describes what QUIC v1 without extensions provides, not what HTTP/3 on v1 requires. When there is only one option, there is only one natural solution.

The reason I suggested to point this out is to allow future HTTP/3 an ability to iterate on this requirement, which could be done in a document that describes a change to the requirement of the frame(s) defined in this spec. That might help to make people aware of when they need to negotiate the extension.

To put it another way. If QUIC v1 offered unreliable and reliable streams. We would likely say that all H3 frames must be delivered on the reliable stream and explain why.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4779#issuecomment-767029977

---

From: kaduk <[email-masked]>
Date: Mon, 25 Jan 2021 22:30:58 -0800

Jana convinced me that the risk of ossification is low (thanks for talking through it!).
Lucas may be on to something, though, in terms of how we describe what we use and what we need, but that could likely be done in the other issue that Mike noted might exist.
I would be okay if we closed this one with no change, but it's not clear that we have fully resolved yet on the latter topic.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4779#issuecomment-767327686

---

From: Lars Eggert <[email-masked]>
Date: Wed, 27 Jan 2021 05:45:34 -0800

Could folks please come to a decision on whether this is "close with no action"?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4779#issuecomment-768294856

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 27 Jan 2021 05:50:30 -0800

I can live with no action.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4779#issuecomment-768297834