- From: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Date: Sat, 17 Feb 2024 16:40:46 +0000
- To: "Michael Welzl" <michawe@ifi.uio.no>, "Kazuho Oku" <kazuhooku@gmail.com>
- Cc: "IETF QUIC WG" <quic@ietf.org>, "HTTP Working Group" <ietf-http-wg@w3.org>
- Message-Id: <939e22d5-1707-4964-9f59-0dea39feebdc@app.fastmail.com>
Hi Michael, On Sat, Feb 17, 2024, at 11:30, Michael Welzl wrote: > Hi, > > QUIC over TCP… I hope that the people doing this are aware of the old work on Minion? If not, see: > https://datatracker.ietf.org/doc/html/draft-iyengar-minion-protocol-02 > https://datatracker.ietf.org/doc/html/draft-iyengar-minion-concept-02 > https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/nowlan > > IIRC, the original Minion idea was to introduce a marker in the bytestream, but the later development (perhaps captured in the drafts above?) worked off the principle that protocols above TCP already have these kinds of markers anyway - i.e., it doesn’t even need a change to the wire protocol, it’s just a “vertical” change about how to talk to the TCP buffer below. > > Considering this, it seems almost silly to me to ignore this and map QUIC over TCP when streams can so nicely be implemented via TCP too, just by “breaking” the TCP API “contract". > > My apologies if this is already a part of the plan - I just wanted to point out this work because at this point, it’s old and might have been forgotten - yet it seems to fit the idea of mapping QUIC over TCP like a glove. I'm aware of minion but haven't looked at it in a long while, thanks for the reminder. I read over it very briefly and I intend to spend more time digesting. However, my intial understanding is that minion has a hard requirement on DTLS, is that correct? Part of the motivation of QUIC on streams, as pointed at in the draft, is to address a concrete problem in HTTP/2 stream limits. There are proposals for how to fix HTTP/2 itself but some of that effort could be invested in swapping over to HTTP/3 using QUIC on streams. Whether that would be successful depends on the change complexity matrix. It's the authors view that many clients and servers already support HTTP/2 over TLS and HTTP/3 (native QUIC) simultaneously, meaning the complexity of adding HTTP/3 over QUIC over TLS is minimized. Mostly because QUIC implementations would need minor tweaks only. As an implementer (not author hat), the requirement to use DTLS would already start to be a put off for me in the above scenario. Can a minion-style (RE)COBS approach could be used with TLS? If so, what benefits would that bring over the current proposal? HTTP/2 is already subject to TCP Head of Line Blocking. Maybe it could be nice to design a replacement that can fix that using TLS too. However, if I understand the minion protocol design (a big if, I'm happy to be corrected), it only supports 4 reorderings. Furthermore, since the "bookends" are in the plaintext stream, it seems trivial for an on-path attacker to interfere with them, opening up a new suite of security issues. Cheers Lucas > > Cheers, > Michael > > > >> On Feb 16, 2024, at 9:24 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: >> >> QUIC on Streams: A polyfill for operating QUIC on top of TCP. >> https://datatracker.ietf.org/doc/html/draft-kazuho-quic-quic-on-streams >> >> HTTP/3 on Streams: How to run HTTP/3 unmodified over TCP, utilizing QUIC on Streams. >> https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-http3-on-streams >> >> As the co-author of the two drafts, let me explain why we have submitted these. >> >> The rationale behind our proposal is the complexity of having two major HTTP versions (HTTP/2 and HTTP/3), both actively used and extended. This might not be the situation that we want to be in. >> >> HTTP/2 is showing its age. We discussed its challenges at the IETF 118 side meeting in Prague. >> >> Despite these challenges, we are still trying to extend HTTP/2, as seen with WebTransport. WebTransport extends both HTTP/3 and HTTP/2, but it does so differently for each, due to the inherent differences between the HTTP versions. >> >> Why are we doing this? >> >> Because HTTP/3 works only on QUIC. Given that UDP is not as universally accessible as TCP, we find ourselves in a position where we need to maintain and extend not only HTTP/3 but also HTTP/2 as a backstop protocol. >> >> This effort comes with its costs, which we have been attempting to manage. >> >> However, if we could create a polyfill for QUIC that operates on top of TCP, and then use it to run HTTP/3 over TCP, do we still need to invest in HTTP/2? >> >> Of course, HTTP/2 won’t disappear overnight. >> >> Yet, by making HTTP/3 more universally usable, we can at least stop extending HTTP/2. >> >> By focusing our new efforts solely on HTTP/3, we can conserve energy. >> >> By making HTTP/3 universally accessible, and by having new extensions solely to HTTP/3, we can expect a shift of traffic towards HTTP/3. >> >> This shift would reduce the necessity to modify our HTTP/2 stacks (we’d be less concerned about performance issues), and provide us with a better chance to phase out HTTP/2 sooner. >> >> 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. >> >> Please let us know what you think. Best regards, >> >> ---------- Forwarded message --------- >> From: <internet-drafts@ietf.org> >> Date: 2024年2月16日(金) 17:15 >> Subject: New Version Notification for draft-kazuho-httpbis-http3-on-streams-00.txt >> To: Kazuho Oku <kazuhooku@gmail.com>, Lucas Pardue <lucas@lucaspardue.com> >> >> >> A new version of Internet-Draft draft-kazuho-httpbis-http3-on-streams-00.txt >> has been successfully submitted by Kazuho Oku and posted to the >> IETF repository. >> >> Name: draft-kazuho-httpbis-http3-on-streams >> Revision: 00 >> Title: HTTP/3 on Streams >> Date: 2024-02-16 >> Group: Individual Submission >> Pages: 5 >> URL: https://www.ietf.org/archive/id/draft-kazuho-httpbis-http3-on-streams-00.txt >> Status: https://datatracker.ietf.org/doc/draft-kazuho-httpbis-http3-on-streams/ >> HTML: https://www.ietf.org/archive/id/draft-kazuho-httpbis-http3-on-streams-00.html >> HTMLized: https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-http3-on-streams >> >> >> Abstract: >> >> This document specifies how to use HTTP/3 on top of bi-directional, >> byte-oriented streams such as TLS over TCP. >> >> Discussion Venues >> >> This note is to be removed before publishing as an RFC. >> >> Discussion of this document takes place on the HTTP Working Group >> mailing list (ietf-http-wg@w3.org), which is archived at >> https://lists.w3.org/Archives/Public/ietf-http-wg/. >> >> Source for this draft and an issue tracker can be found at >> https://github.com/kazuho/draft-kazuho-httpbis-http3-on-streams. >> >> >> >> The IETF Secretariat >> >> >> >> >> -- >> Kazuho Oku
Received on Saturday, 17 February 2024 16:41:14 UTC