Dear Kazuho, Lucas and HTTP/QUIC designers,
We would like to attract your attention on the TCPLS design that answers
several of your motivations:
- Supports making HTTP/3 more universally usable, having the same
semantic mapping than QUIC.
- Would contribute to phase out HTTP/2, and bring more security to HTTP.
- Minimal impact on QUIC implementations.
TCPLS is a TLS1.3/TCP intertwined stack design offering the same
benefits than QUIC (HoL blocking avoidance, migration) but with TCP
instead of UDP, leading to higher efficiency, and likely smoother
deployment (anywhere TLS 1.3 works, TCPLS should work too). There are a
few documents covering TCPLS for those who are interested:
- An APNIC blogpost with a 10,000 feets overview comparison to QUIC --
https://blog.apnic.net/2022/05/24/tcpls-modern-transport-services-with-tcp-and-tls/
- The original ACM CoNEXT'21 publication --
https://orbi.uliege.be/bitstream/2268/264667/1/paper.pdf
- An IETF draft where the initial design matured, and continues to
evolve -- https://datatracker.ietf.org/doc/draft-piraux-tcpls/
- An implementation of the TCPLS draft supporting version 02 by Maxime
Piraux: https://github.com/mpiraux/rapido
it seems that one of the key points of your proposal is to have limited
impact on QUIC implementers, by stripping away QUIC of some of its
features (migration, and HoL blocking avoidance), and conserving the
remaining message formatting, with minor tweaks. That makes total sense
to get this fast and working, however we also loose interesting features
on the way.
We have worked with Olivier Bonaventure and Maxime Piraux on some
iterations of the TCPLS design during the last years. Some of the
solutions that we found are probably also applicable to the problem that
you want to tackle and we'd be happy to collaborate and discuss with you
and the working group on these problems. We also have running code as an
extension of picotls (rapido) and Hosam Elkoulak is working on an
independent implementation in rust, and improvements of the current draft.
One key question for this discussion: would future HTTP/3 services atop
TCP be "ok" to loose the cool QUIC features (ie., multiplexing and
connection migration) if they have to fallback to this HTTP/3 TCP solution?
Best regards,
Florentin
Le 16/02/24 à 09:24, Kazuho Oku a écrit :
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
<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
<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: <[email protected]>
Date: 2024年2月16日(金) 17:15
Subject: New Version Notification for
draft-kazuho-httpbis-http3-on-streams-00.txt
To: Kazuho Oku <[email protected]>, Lucas Pardue <[email protected]>
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
<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/
<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
<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
<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 ([email protected]), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/
<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
<https://github.com/kazuho/draft-kazuho-httpbis-http3-on-streams>.
The IETF Secretariat
--
Kazuho Oku
