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> Fri, 16 February 2024 10:51 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 467FBC15155E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 16 Feb 2024 02:51:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.755
X-Spam-Level:
X-Spam-Status: No, score=-2.755 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_DNSWL_BLOCKED=0.001, 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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=w3.org header.b="hiBvDUxl"; dkim=pass (2048-bit key) header.d=w3.org header.b="Xu2rUFPv"
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 6w9KS4crPzdW for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 16 Feb 2024 02:50:58 -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 75CA6C1CAF2B for <httpbisa-archive-bis2Juki@ietf.org>; Fri, 16 Feb 2024 02:50:36 -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=MITGtDaqJgl/eM+9K+5McRWOraKIiqs6ow4D05jNjBI=; b= hiBvDUxlRmmwLZhtW2wM4FPXLE2cFbrZCUIRaL46IqZvjd2Ph7HInjZ3fXpT5Vd8Rxg0SUONyFe3E S1w3yf7nYLq/eNZrKuCsy7KlolreW2sCWO8LJpZe2rF8byPWjGb09ihntwAI6TbMxZaKBzoSNF3V/ oHFKwt+xe9hN5zOe0K3hMQzK8F+Dum8fRT4Irju3cN1AmIGznjCsSHeRVxr2uNEKJksFVaumDl0T5 bHxDLEK+yBghMeOUj5g40kvDyhxbEkl3xunPGK0PofUCVf5H+TUpmScA7Gc7XBtd0+a8wlHC7r34M dmDeu1m7hcpDltGmWki/s613zxdHqrmhlQ==;
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ravnU-009xHY-1I for ietf-http-wg-dist@listhub.w3.org; Fri, 16 Feb 2024 10:50:24 +0000
Resent-Date: Fri, 16 Feb 2024 10:50:24 +0000
Resent-Message-Id: <E1ravnU-009xHY-1I@lyra.w3.org>
Received: from pan.w3.org ([3.222.182.102]) 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 1ravnS-009xGS-Cw for ietf-http-wg@listhub.w3.org; Fri, 16 Feb 2024 10:50:22 +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=MITGtDaqJgl/eM+9K+5McRWOraKIiqs6ow4D05jNjBI=; t=1708080622; x=1708944622; b=Xu2rUFPvn9TejmKEx4ebqzie3t+tU3TyQbCMc9gh8KNLUVu 0qDRWp8L5nVvawfnmhRm0QTR22KjlotLEWqpDiL6hbAXf3+LfLseCs5hglPUMbYelQylNlS6d1NRg xjG8WIVSaUaXK50dBJGU06ZCfnkgfYiVEKnXhY55uWhB0sKmaB2HQIOjZ85Ke4AJxcHm/Oc68mIZc 6fbu8HKx+NidI+chNqUIAAgMXBnSPJHSnmNj87iExneWWPX8nyZB274laOaZl7sBcsWGTvQrS829A SJO0J1CIs4zkmkSKLbex9S2tpbGrsnZ+YmkMgGlM3LlcriOpfrhLYEZJEBvKv6PA==;
Received-SPF: pass (pan.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 pan.w3.org with esmtp (Exim 4.96) (envelope-from <w@1wt.eu>) id 1ravnR-000SDM-0d for ietf-http-wg@w3.org; Fri, 16 Feb 2024 10:50:22 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 41GAo8kR026962; Fri, 16 Feb 2024 11:50:08 +0100
Date: Fri, 16 Feb 2024 11:50:08 +0100
From: Willy Tarreau <w@1wt.eu>
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, Lucas Pardue <lucas@lucaspardue.com>
Message-ID: <20240216105008.GA25077@1wt.eu>
References: <170807134367.25372.9131938145722079298@ietfa.amsl.com> <CANatvzyLJnZH9UHaSoMWbv20VhEtAzY7HqRHCSWt-O65f24uwQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CANatvzyLJnZH9UHaSoMWbv20VhEtAzY7HqRHCSWt-O65f24uwQ@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DMARC_MISSING=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: pan.w3.org 1ravnR-000SDM-0d 948000e96d72af2201b0f6a7075deb5f
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/20240216105008.GA25077@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51782
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 Kazuho, Lucas, On Fri, Feb 16, 2024 at 05:24:59PM +0900, Kazuho Oku wrote: > 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 These are super interesting! I've expressed interest in the past in trying to port H3 to TCP though I didn't have all the gory details of the protocol by then. More recently I discussed this possibility a few times with my coworkers who implemented and maintain QUIC in haproxy, as a cleaner "backend" protocol. What I'm seeing with haproxy is that we generally have H1/H2/H3 for the front connection, and H1 most often for the connection going to the server. The reason is that H2 is not very interesting there because: - it doesn't support multiple client multiplexing well over the same connection due to head of line blocking, unless you use a super small window ; - the max streams supported by the server isn't known upfront and can sometimes require to retry failed requests, or to be very conservative on the number of parallel requests until you get the server's SETTINGS. Of course you can put that in a config, but with some automated deployments you just don't know. - the default max frame size is not efficient enough to perform zero-copy transfers, and increasing it is just going to make HoL worse. H1 on the other hand has the problem of not being able to abort a retrieval without breaking the connection. One option could consist in dealing with single-stream H2 with large frames but that's not necessarily what servers will do. I've been thinking that using single-stream H3 connections would be a better option for this. It would keep the efficiency of HPACK and QPACK header compression (even if for reused connections it's less efficient), and some lightweight framing that could possibly improve transfer efficiency and aborts (this is still to be verified). And of course, dealing with a better offset-based in instead of credit-based flow-control is appealing. So for me, H3 over TCP could be a nice upgrade to H1 on the backend with less hassles than H2, and QUIC over TCP could probably just replace H2 on the backend. Also some of the TTFB benefits of QUIC over UDP (0-RTT etc) are irrelevant on the backend because there you mostly keep many connections open for a long time. I'm very interested in seeing what it could become! Cheers, 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