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)
Paul Vixie <paul@redbarn.org> Sat, 17 February 2024 10:21 UTC
Return-Path: <paul@redbarn.org>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1268BC14F690 for <quic@ietfa.amsl.com>; Sat, 17 Feb 2024 02:21:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redbarn.org
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 4V5LnkyvnUEs for <quic@ietfa.amsl.com>; Sat, 17 Feb 2024 02:20:56 -0800 (PST)
Received: from util.redbarn.org (util.redbarn.org [IPv6:2001:559:8000:cd::222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B676EC14F689 for <quic@ietf.org>; Sat, 17 Feb 2024 02:20:50 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.redbarn.org", Issuer "RapidSSL TLS RSA CA G1" (not verified)) by util.redbarn.org (Postfix) with ESMTPS id C2EC71A2921; Sat, 17 Feb 2024 10:20:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1708165247; bh=1Cw2X47h9S/43S4ROywNcvfyTU5OmL/TCKwwqX4UK6E=; h=Date:Subject:In-Reply-To:References:From:To:Cc; b=m82KPIETWoDNZM6xfBt7on8L2D9B+wn2vfSakFabeXrVIxcejvbN/LFAswcGGb6nJ dd7NfnOnoVfTczgCIiTumIBG8pe1zrknHPNuLv+1RRAc42VuXZQRNaiPSCstCsoUFH yG0y9Z8IptOYdkPdOtphlVPug1UNmwdt9D5/ustc=
Received: from [10.97.245.236] (unknown [5.33.0.222]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 2C869C3F1F; Sat, 17 Feb 2024 10:20:44 +0000 (UTC)
Date: Sat, 17 Feb 2024 11:20:38 +0100
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)
Message-ID: <5c3c0f38-0bb4-4775-8420-e8ba7c362a2a@redbarn.org>
In-Reply-To: <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> <20240217061123.GA29115@1wt.eu>
From: Paul Vixie <paul@redbarn.org>
To: Willy Tarreau <w@1wt.eu>, Christian Huitema <huitema@huitema.net>
Cc: Kazuho Oku <kazuhooku@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, Lucas Pardue <lucas@lucaspardue.com>, Hugo Landau <hlandau@openssl.org>, IETF QUIC WG <quic@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.boxer.email_361975687568484"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/u-yCnInc9QeZfD91PV55nCl1pVw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Feb 2024 10:21:04 -0000
<<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.>> For networks owned and operated by their users, and for operators who will be held responsible by their peers and transits for the signals they emanate, any protocol that cannot be monitored and filtered will be firewalled off entirely. Ietf can increase the costs of doing so but that will be the only outcome. Perhaps a better strategy than iterative one upmanship would be to formally recognize network operators and to legitimize their concerns. This could lead to cooperative signaling and could slow the increase in protocol complexity. This draft describes an increase in complexity to combat existential inevitabilities of the installed base. p vixie On Feb 17, 2024 07:11, Willy Tarreau <w@1wt.eu> wrote: 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… Hugo Landau
- 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… Lucas Pardue
- Re: Proposal Towards Universal HTTP/3, with a pol… Behcet Sarikaya
- Re: Proposal Towards Universal HTTP/3, with a pol… 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… Watson Ladd
- Re: Proposal Towards Universal HTTP/3, with a pol… Christian Huitema
- Re: Proposal Towards Universal HTTP/3, with a pol… Willy Tarreau
- Re: Proposal Towards Universal HTTP/3, with a pol… Paul Vixie
- Re: Proposal Towards Universal HTTP/3, with a pol… Kazuho Oku
- Re: Proposal Towards Universal HTTP/3, with a pol… Michael Welzl
- Re: Proposal Towards Universal HTTP/3, with a pol… Hugo Landau
- Re: QUIC on streams compared to Minion (was Re: P… Lucas Pardue
- Re: Proposal Towards Universal HTTP/3, with a pol… Matt Mathis
- QUIC on streams compared to Minion (was Re: Propo… Lucas Pardue
- Re: QUIC on streams compared to Minion (was Re: P… Michael Welzl
- Re: QUIC on streams compared to Minion (was Re: P… Michael Tuexen
- Re: Proposal Towards Universal HTTP/3, with a pol… Lucas Pardue
- Re: Proposal Towards Universal HTTP/3, with a pol… Florentin Rochet
- Re: Proposal Towards Universal HTTP/3, with a pol… Dmitry Adamushka
- Re: Proposal Towards Universal HTTP/3, with a pol… Roberto Peon
- 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… Roberto Peon
- 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… Lucas Pardue
- Re: Proposal Towards Universal HTTP/3, with a pol… Lucas Pardue