Responding with the understanding that we’re discussing technical details, not the recharter itself.
2025年6月3日(火) 10:30 Christian Huitema <[email protected]>: > Sorry I missed the meeting. I read the notes, and the zulip. I am glad > that most of the points I would have made were made by others. Two big > points actually: > > 1) please don't force me to implement H2. Doing H1 + H3 is good enough. > +1. WT/H2 allows WebTransport to run over HTTP/2. However, when our goal is a QUIC-compatible substrate that rides directly on bidirectional streams, any HTTP layer—regardless of the HTTP version—introduces avoidable indirection. Once we agree to leave HTTP out of scope, the only remaining issue is the wire encoding for frames and Transport Parameters (TPs). Regardless of which option we choose, those frames or capsules will be carried *directly* on the byte stream; HTTP framing or flow control does not apply. Option a) Use QUICv1 encodings * transfer QUIC frames / TPs as-is * disallow frames & TPs unrelated to stream/datagram delivery * add a new max-payload-length TP for STREAM frames to compensate for the loss of packet boundaries Option b) Use WT/H2 encodings * wire format: Capsule TLV encoding (RFC 9297) * map each QUIC frame to a capsule type * silently drop unknown capsules (unlike QUIC’s connection error rule) * map each applicable TP to its own HTTP/2 setting; initial per-stream limits may be encoded as text[1] Assuming our goal is a stream-friendly counterpart to QUIC v1, I favor Option A. If QMux were to adopt a different wire format, anyone writing or maintaining QUIC and its extensions would have to describe, review, and test two parallel encodings—with different semantics—for every new feature. That duplication would multiply editorial effort and make it harder to keep the two tracks in lock-step as the protocol evolves. I acknowledge that the WT/H2 encoding appeals to deployments that must support WebTransport over HTTP/2. However, QMux is intended as a fallback substrate for any deployment that speaks QUIC; many of those would have no WT/H2 stack at all, and for them re-using the existing QUIC v1 encoding is clearly the lower-cost path. In short, between the two available encodings, the overall trade-off favors QMux adopting the QUIC v1 format. > > 2) would be really nice if QUIC-on-streams had the same encryption model > as QUIC, bringing in the QUIC Initial/handshake/0RTT/1RTT packets. > > TLS/1.3 will provide these 4 types of TLS *records* and allow applications to send 0-RTT data, when TLS/1.3 is used beneath QMux. At least that is the design that we have in quic-on-streams-00. [1] The current draft allows only a subset of parameters to be exchanged using the WebTransport-Init header. Is this intentional or an oversight? > -- Christian Huitema > > On 6/2/2025 1:33 PM, Lucas Pardue wrote: > > This is taking place in 30 minutes. MeetEcho link > https://meetings.conf.meetecho.com/interim/?group=c641cb96-5ed6-42d3-a95f-495c988dfed8 > > > > On Tue, May 27, 2025, at 23:00, Lucas Pardue wrote: > >> Hi folks, > >> > >> This email is a reminder that we'll be holding a virtual interim next > week on the topic of QMux: 2025-06-02 21:00-23:00 UTC. The datracker page > has further inforation including the MeetEcho link that we'll be using [1]. > Participation is open but a free datatracker account is required. > >> > >> An agenda has been posted [2]. As usual this is subject to change up to > and including the meeting itself. This meeting will run slightly different > from past meetings focused on adopted documents and issues. Time will be > dedicated to sufficient discussion of the QMux topic, with the focus being > to iterate on the scope of work to do and proposed charter text to permit > that in the QUIC WG. As usual, any meeting outcomes will be brought back to > the list for confirmation. > >> > >> Cheers > >> Lucas & Matt > >> QUIC WG Co-chairs > >> > >> > >> [1] - > https://datatracker.ietf.org/meeting/interim-2025-quic-01/session/quic > >> [2] - > https://github.com/quicwg/wg-materials/blob/main/interim-25-06/agenda.md > > -- Kazuho Oku
