Re: Proposal Towards Universal HTTP/3, with a polyfill of QUIC for TCP (Fwd: New Version Notification for draft-kazuho-httpbis-http3-on-streams-00.txt)

[Kazuho Oku <[e-mail]>]

2024年2月17日(土) 7:59 Watson Ladd <[e-mail]>:
>
> On Fri, Feb 16, 2024 at 12:29 AM Kazuho Oku <[e-mail]> 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?

Thank you for your comments!

Regarding the complexity of integrating QUIC on Streams support into QUIC
extensions, I concur that it's unlikely to be a significant burden.

Among QUIC extensions, there are one RFC and one WG-adopted draft related
to how data is being sent.

RFC 9297 defines how datagrams can be sent. Its port is already defined in QUIC
on Streams draft Section 8.1
<https://kazuho.github.io/draft-kazuho-quic-quic-on-streams/draft-kazuho-quic-quic-on-streams.html#name-unreliable-datagram-extensi>.
The only change there is the inference of frame length when utilizing the
length-omitting variant of the DATAGRAM frame. It is changed the same way
as the STREAM frame of QUIC v1 has been changed.

draft-ietf-quic-reliable-stream-reset defines how streams can be reset
while delivering stream data up to a specified offset. I believe no
alterations are necessary for its compatibility with QUIC on Streams.

It is definitely true that all the TCP-related limitations will persist.
The idea here is to define a polyfill of QUIC beneath application protocols
so that all of them (i.e., H3, WebTransport over H2, and new protocols
developed on top of QUIC) can operate on top of TCP without (or with
minimal) modification.

>
> Sincerely,
> Watson



-- 
Kazuho Oku