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)

[Willy Tarreau <[e-mail]>]

Hi Christian,

On Fri, Feb 16, 2024 at 08:26:55PM -0800, Christian Huitema wrote:
> 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?

It depends. I've heard some resistance against QUIC from people operating
their own infrastructure who were quite relieved from having managed to
totally get rid of UDP in their infrastructure because UDP is significantly
more prone to DDoS than TCP, and for them, having to re-enable UDP is
perceived as a regression. I'm well aware that it's possible (and to some
extents easier) to recognize QUIC datagrams and implement some anti-DDoS
mechanism on them, but I can also understand the concerns of those who
had to suffer from this for years and who are constantly responding "no"
to their customers asking for HTTP/3.

I anticipate that some of these might feel safer offering HTTP/3 over
QUIC over TCP to their customers. Of course, until browsers implement it,
it will be useless, but it already changes the response to "we have H3,
it's not our fault if browsers don't use it", then under maintained
pressure they might be tempted to go a bit further and finally try to
enable QUIC on some servers and see what happens. Thus QUIC over TCP
might constitute a less frightening first step for some future adopters.

And finally there are probably some applications that would like to use
APIs over HTTP/3 inside the infrastructure, which is currently rejected
for the same reasons (no UDP here) where H3S could be a nice option.

Regards,
Willy