- From: Watson Ladd <watsonbladd@gmail.com>
- Date: Fri, 16 Feb 2024 14:59:27 -0800
- To: Kazuho Oku <kazuhooku@gmail.com>
- Cc: IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, Lucas Pardue <lucas@lucaspardue.com>
On Fri, Feb 16, 2024 at 12:29 AM Kazuho Oku <kazuhooku@gmail.com> wrote: > > Hello QUIC and HTTP enthusiasts, > > We, Lucas and I, have submitted two drafts aimed at broadening the reach of HTTP/3 - yes, making it available over TCP as well. We are eager to hear your thoughts on these: > > Some might argue that implementing a polyfill of QUIC comes with its own set of costs. However, it is my understanding that many QUIC stacks already have the capability to read QUIC frames other than from QUIC packets, primarily for testing purposes. This suggests that the effort would be more about leveraging existing code paths rather than writing new code from scratch. Furthermore, a QUIC polyfill would extend its benefits beyond just HTTP, by aiding other application protocols that aim to be built on top of QUIC, providing them accessibility over TCP. I have some mild skepticism about this design. Each QUIC extension now has to consider TCP transport, vs. each HTTP extension considering H2 or H3. However I think the necessary change isn't that much for QUIC over TCP vs. H2/H3, unless the extension does a lot of the prohibited things. You don't however get much improvement: H2's TCP related limitations remain. Is this need for a choice supposed to also apply to non-HTTP QUIC applications? Sincerely, Watson
Received on Friday, 16 February 2024 22:59:44 UTC