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 <w@1wt.eu> Sat, 17 February 2024 06:12 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=ietf.org@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC44C15153C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 16 Feb 2024 22:12:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.759
X-Spam-Level:
X-Spam-Status: No, score=-2.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=w3.org header.b="IR8ssqnU"; dkim=pass (2048-bit key) header.d=w3.org header.b="SxCOiqci"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEOMCFmqgYCo for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 16 Feb 2024 22:12:19 -0800 (PST)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB895C18DB88 for <httpbisa-archive-bis2Juki@ietf.org>; Fri, 16 Feb 2024 22:12:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Cc:To:From:Date:Reply-To; bh=Zq1iOCf8Cc+V6mdtjDsGtaJiIrP6/KxbwCgwbLCwo8U=; b= IR8ssqnUX6jfiPCECm7fLGzQWhgk4i60Ii5fiOQp6O4yVth8pCjTgcvJtIiBBxh4Z2RDYSdedElFL LaZUe1mOpHGBbRmA5JTtPuTAkGYuU8G1pJM8/rBmePlfRQmrFv6ODJZo3EzKbc/VPQsjIx3nXuR1j Fp7cI4XPjxp7e7aFx6b9n5z/TewP/cUxYsPba9XvcoDACPIUw3VQYZvVpZzoB1CdFX/j/5PXZJxCY wcZJTwSX09/5q1Gl/w3xL5JK7RICrmLVoIsY5gi/bZezl85EtF3F7VmG3yjosH63NPrvipXav7f4d bHn3+ZEvhKhHLJQVcK8fCETi4WhTz8+DQQ==;
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1rbDvT-00C4k2-K3 for ietf-http-wg-dist@listhub.w3.org; Sat, 17 Feb 2024 06:11:51 +0000
Resent-Date: Sat, 17 Feb 2024 06:11:51 +0000
Resent-Message-Id: <E1rbDvT-00C4k2-K3@lyra.w3.org>
Received: from puck.w3.org ([34.196.82.207]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <w@1wt.eu>) id 1rbDvR-00C4iv-BD for ietf-http-wg@listhub.w3.org; Sat, 17 Feb 2024 06:11:49 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject: Cc:To:From:Date:Reply-To; bh=Zq1iOCf8Cc+V6mdtjDsGtaJiIrP6/KxbwCgwbLCwo8U=; t=1708150309; x=1709014309; b=SxCOiqcinuIICmBH+WnJoEwpAHBtlUs4+28WTsHYTlzXAh9 aWrftXbgmcb3uCiDIzdY3PC5TzBR+9NbdWSsB/r3f7J1uo3ov/CEvcG4QRv5WAynetBz0jzFdp32f N0cQ8cWDcSZjiTEk9COYCj4ZYxL0Ul+JUOdpbDenp2ONb+S1oyrdaCvf+m7fE0x/HfQ2hSSzSw96t M8zWhMuc0WVpEeTm9aYsVzJpErHOv0qqV4rKEz3J9G1zLl6ZQCqZTn28NOWWzOIW2SAIordF1Lm5H 6WJJtOpOiC5B0wj43nPysnyCQlYFMHtM7N/CBW3+vb7ML3u3lZyrFfQFWltVkJqg==;
Received-SPF: pass (puck.w3.org: domain of 1wt.eu designates 163.172.96.212 as permitted sender) client-ip=163.172.96.212; envelope-from=w@1wt.eu; helo=1wt.eu;
Received: from ded1.1wt.eu ([163.172.96.212] helo=1wt.eu) by puck.w3.org with esmtp (Exim 4.96) (envelope-from <w@1wt.eu>) id 1rbDvQ-000fRr-0y for ietf-http-wg@w3.org; Sat, 17 Feb 2024 06:11:49 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 41H6BOA0029150; Sat, 17 Feb 2024 07:11:24 +0100
Date: Sat, 17 Feb 2024 07:11:23 +0100
From: Willy Tarreau <w@1wt.eu>
To: Christian Huitema <huitema@huitema.net>
Cc: Kazuho Oku <kazuhooku@gmail.com>, Hugo Landau <hlandau@openssl.org>, IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, Lucas Pardue <lucas@lucaspardue.com>
Message-ID: <20240217061123.GA29115@1wt.eu>
References: <170807134367.25372.9131938145722079298@ietfa.amsl.com> <CANatvzyLJnZH9UHaSoMWbv20VhEtAzY7HqRHCSWt-O65f24uwQ@mail.gmail.com> <Zc8kDgXmkEku_61q@camelot.lhh.devever.net> <CANatvzwVpe2k9gjKFfkuudueDndS0Btgmx-_LWSajt=6K2MxMQ@mail.gmail.com> <f23e13a8-f8e7-4fb4-bd58-ebd880613a37@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <f23e13a8-f8e7-4fb4-bd58-ebd880613a37@huitema.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-W3C-Hub-Spam-Status: No, score=-9.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DMARC_MISSING=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: puck.w3.org 1rbDvQ-000fRr-0y 76ad3b015d2e3d75d2bd73a53a86d79f
X-Original-To: ietf-http-wg@w3.org
Subject: 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)
Archived-At: <https://www.w3.org/mid/20240217061123.GA29115@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51792
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/email/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
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
- Proposal Towards Universal HTTP/3, with a polyfil… Kazuho Oku
- Re: Proposal Towards Universal HTTP/3, with a pol… Stefan Eissing
- Re: Proposal Towards Universal HTTP/3, with a pol… Victor Vasiliev
- Re: Proposal Towards Universal HTTP/3, with a pol… Willy Tarreau
- Re: Proposal Towards Universal HTTP/3, with a pol… Poul-Henning Kamp
- Re: Proposal Towards Universal HTTP/3, with a pol… Watson Ladd
- Re: Proposal Towards Universal HTTP/3, with a pol… Kazuho Oku
- Re: Proposal Towards Universal HTTP/3, with a pol… Lucas Pardue
- Re: Proposal Towards Universal HTTP/3, with a pol… Kazuho Oku
- Re: Proposal Towards Universal HTTP/3, with a pol… Kazuho Oku
- Re: Proposal Towards Universal HTTP/3, with a pol… Kazuho Oku
- Re: Proposal Towards Universal HTTP/3, with a pol… Christian Huitema
- Re: QUIC on streams compared to Minion (was Re: P… Michael Tuexen
- Re: QUIC on streams compared to Minion (was Re: P… Lucas Pardue
- QUIC on streams compared to Minion (was Re: Propo… Lucas Pardue
- Re: Proposal Towards Universal HTTP/3, with a pol… Lucas Pardue
- Re: Proposal Towards Universal HTTP/3, with a pol… Lucas Pardue
- Re: Proposal Towards Universal HTTP/3, with a pol… Willy Tarreau
- Re: Proposal Towards Universal HTTP/3, with a pol… Matt Mathis
- Re: Proposal Towards Universal HTTP/3, with a pol… Kazuho Oku
- Re: Proposal Towards Universal HTTP/3, with a pol… Lucas Pardue
- Re: Proposal Towards Universal HTTP/3, with a pol… Lucas Pardue
- Re: Proposal Towards Universal HTTP/3, with a pol… Lucas Pardue