On 2/16/2024 3:39 PM, Kazuho Oku wrote:
2024年2月16日(金) 18:00 Hugo Landau <[email protected]>:
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,
It's an interesting proposal. Looks fairly sensible.
I could see a lot of other uses also for having a mapping of the QUIC
application-level semantics without QUIC itself, such as for diagnostic
use or intra-DC backhaul of incoming traffic.
I question the utility of implicit length signalling. Unless there's a
real use for this (maybe there is and I'm just not seeing it) I would
probably just prohibit these encodings. The max_frame_size transport
parameter proposed here cannot be reduced below 16384. So you're saving
at most 3 bytes (to encode 16384) for every 16384 bytes. That would seem
to yield an efficiency increase of 0.018%. For larger max_frame_size
values this obviously gets even smaller.
Is there a rationale to supporting this I'm not seeing?
Thank you for your comments!
Regarding your question, in the initial draft, we attempted to limit
changes to the way frames are communicated, while preserving the frame
encoding of QUIC v1 unchanged. The purpose of this approach is to
maximize code reuse between QUIC v1 and QUIC over Streams.
For STREAM frames that lack length fields, we considered two options:
a) defining a method to deduce the length from another source, or
b) prohibiting the use of such frames.
We opted for option (a) for consistency, under the assumption that it
would not be more complex to implementations than (b).
However, it was a narrow decision. I acknowledge that opting for (b)
would also be straightforward to implement, especially since STREAM
frames lacking length fields are identified by specific frame types
(namely, 0x08, 0x09, 0x0c, 0x0d), and considering we're already
restricting the use of certain QUIC v1 frames.
I like this design. I know that I will have to add a QUIC over TCP
option to cross some firewalls. QUIC over Streams looks fine, and is a
lesser burden for me than having to implement H2. But then, let's take a
step back.
We want a TCP solution because some networks block UDP. AFAIK, they do
that because they want to monitor the TCP connections, either because
they rely on features of TCP to manage a NAT, or because they rely on
features of HTTP or H2 to manage proxies. I am concerned that the
networks that block QUIC over UDP will also block QUIC over TCP, because
they expect H2, not H3S.
Do we have data on the fraction of networks that block UDP today but
would let H3S through?
-- Christian Huitema
