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)

Lucas Pardue <lucas@lucaspardue.com> Tue, 27 February 2024 17:23 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 9098FC14CF18 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 27 Feb 2024 09:23:11 -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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=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="DB88gPdS"; dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=w3.org header.b="NpJPplzv"; dkim=neutral (2048-bit key) reason="invalid (signature is expired)" header.d=lucaspardue.com header.b="wvnJMDaR"; dkim=neutral (2048-bit key) reason="invalid (signature is expired)" header.d=messagingengine.com header.b="ev26/kbm"
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 bZOWl6I_eTN8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 27 Feb 2024 09:23:07 -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 D8666C14F71C for <httpbisa-archive-bis2Juki@ietf.org>; Tue, 27 Feb 2024 09:23:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:Content-Type:Cc:To:From:Date:References:In-Reply-To: Message-Id:MIME-Version:Reply-To; bh=WiAqT9Rrj4aTPI0zFmhhpykTzC0lo6fOAy2UMjT3whs=; b=DB88gPdSx71BQtoBIWF3Bg/6SG JL9wBTq/+AaWBw/GvR4yBBpn3XZUVGFijWajczoQij/GoSmU2SsJIuwtcRBYvo9egU/LNS7X3llVq fkNbgnLxCwU6eeDJSjvroh4BSVrtDwCl2qptq4OZUxueBluBsuh4q6ttF4Ko/BfqUmSDFn79GXIHW MUBYogxAR4SjyPTxsZsTYmIi8X8Sb8nbIfT35Ti632vDiQvB1ovr+S+/DMBkq7sCHfycMZCPL0K/K 6qmLaf8ZXeFnwu3O4W2Byuj7UPDPl6MRC79mGEwYitJCe5aGJOgP/zOjipwqPntAOwrLcIvq4JEI/ 9Lruy1eQ==;
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1rf0aj-002oyg-9S for ietf-http-wg-dist@listhub.w3.org; Tue, 27 Feb 2024 16:46:05 +0000
Resent-Date: Tue, 27 Feb 2024 16:46:05 +0000
Resent-Message-Id: <E1rf0aj-002oyg-9S@lyra.w3.org>
Received: from www-data by lyra.w3.org with local (Exim 4.94.2) (envelope-from <lucas@lucaspardue.com>) id 1rf0ah-002oui-Fq for ietf-http-wg@listhub.w3.org; Tue, 27 Feb 2024 16:46:03 +0000
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 <lucas@lucaspardue.com>) id 1redft-00H9l0-5W for ietf-http-wg@listhub.w3.org; Mon, 26 Feb 2024 16:17:53 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Content-Type:Subject:Cc:To:From:Date:References:In-Reply-To: Message-Id:MIME-Version:Reply-To; bh=WnNG5bc3f3FGLGri716pQ+vATYolRahV78Wrxz3md9g=; t=1708964273; x=1709828273; b=NpJPplzvT/YnAklQ91gvx33g5o65qyP0LMC1ooNgvSiOSM/zHpxhgazDTAjJOoHtQiCbozAfdiv +CsUN2H9OEuJTobL/yRT5m8hfO4dSIrflr3GRf5zkHzSByujnIaLFnmbtYN3d9B4CQU/JHFHTFRL0 YJEQn70rBSjmlLm+D/cHP6tPYRN/nu12oSlxDcWVbRG41FBHdZ+DSfh0LzIJo1rfnGs6pTb5orLSL x7elOch4tenJHPt6QgcVKOMDFAsasUFX+W08663j3Kp2yEp6yC8sy/I5FMqQ6CayMiiBnCjaCZsNj ApnM56GAD5e3lTm0uWcghYK94V/C6zyhvDOg==;
Received-SPF: pass (pan.w3.org: domain of lucaspardue.com designates 103.168.172.152 as permitted sender) client-ip=103.168.172.152; envelope-from=lucas@lucaspardue.com; helo=fhigh1-smtp.messagingengine.com;
Received: from fhigh1-smtp.messagingengine.com ([103.168.172.152]) by pan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <lucas@lucaspardue.com>) id 1redfs-004P9B-0e for ietf-http-wg@w3.org; Mon, 26 Feb 2024 16:17:52 +0000
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfhigh.nyi.internal (Postfix) with ESMTP id E9338114008E; Mon, 26 Feb 2024 11:17:48 -0500 (EST)
Received: from imap53 ([10.202.2.103]) by compute3.internal (MEProxy); Mon, 26 Feb 2024 11:17:48 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucaspardue.com; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm2; t=1708964268; x= 1709050668; bh=WnNG5bc3f3FGLGri716pQ+vATYolRahV78Wrxz3md9g=; b=w vnJMDaRjkIJCtY3ZM34Od0bDBjfU/hA/HTWrzXRltmSe/DyuQifM6/x6gTt89Pcn sSgB+I+a1W6AXPGOCC5UkCoRr030azvTKRencQ17ORXmrXR6M2Y+q71DKwoOp4TP xuhdvHGBEMxeDJOy9vRC5CEpPTfoZshHTz3BtUJCUZjxD5grAsE2KkSQY+EgiTeS RSnwnnAfMTAxiyynmJwA7AhYIqEaNJrRHyoYH30ECPNNYqvQPkARydUynknMZrf8 Rx46miUrfqzUaZVXZGPD5m0plaxQt8wxz3UhOcP7HO2gB3bWr2xze63lih2/JSir 8T70wi1OPDGptG6JgQbNQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1708964268; x=1709050668; bh=WnNG5bc3f3FGLGri716pQ+vATYol RahV78Wrxz3md9g=; b=ev26/kbmn8SPDZNO9pM7D+PbcQ9FPhKdpFq2VF7mzCn5 nUwz8nrnRsjIihyBr0n4ILWnMfg/VnjF87C7Ow2DXZH0cpSteJ7GeX7XA4d5HnWu kJwbiN60KNLI9PlhjXY5RJ9eYCRTrAYLcojd4TGz+EU9pfY8hQ3SsGsMYa1wJAhG K9kKjZxlgpbN9+i3kmbYrHaZA8E6qRCYgkHBxPkyQjzZZxkP8P3p9q5CSyn8CR8U b37uXHQuSHT0iIBWcQAK9lLsieaNc9pAQfUZlj+gfFp+iZ37Tu0vChr7ujeC/hcQ adQzlVgGK1QadZex4CtbmUn3JaAWfZ2ab0yG5svwzg==
X-ME-Sender: <xms:rLncZZd4pRmLs3VVjTMvDVzarJMrStNPQUcNI83bsSdcmzKxbaJELg> <xme:rLncZXMe9vranSrLKB-6EkbeIuhboSSPVsFosRYVypgl-oEYp0LkyeL-c2bRe3KdN mCNQmS8ySPpLdr0YPI>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrgedvgdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesrgdtreerreerjeenucfhrhhomhepfdfnuhgt rghsucfrrghrughuvgdfuceolhhutggrsheslhhutggrshhprghrughuvgdrtghomheqne cuggftrfgrthhtvghrnheptdffgeffieehfedvgfekvdetvdeltefggfeufefhveevhfev hfefteegtdethfdunecuffhomhgrihhnpehrfhgtqdgvughithhorhdrohhrghdpfiefrd horhhgpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep mhgrihhlfhhrohhmpehluhgtrghssehluhgtrghsphgrrhguuhgvrdgtohhm
X-ME-Proxy: <xmx:rLncZSihir3QA6PyVo9mPRv_HRkLNS7ARN57MlVl80Cf-_5syx4w6A> <xmx:rLncZS_6k8YqS6sO9aYJtSF1NMzg2YCVh69W8zpQoEYGo1Xbf5eblg> <xmx:rLncZVuEXyG5AYclBRCKJX3A528cWYV2A0o2156ujiX9gTGcnzWY1A> <xmx:rLncZfLHO8Pd9sbxHfMHjmWZLm_64RbWuDqYKmpt9hMlJmXtv6qjaw>
Feedback-ID: i23b94938:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id AA0063640071; Mon, 26 Feb 2024 11:17:48 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.11.0-alpha0-153-g7e3bb84806-fm-20240215.007-g7e3bb848
MIME-Version: 1.0
Message-Id: <63c9787e-3e76-4a47-80e3-ba4d7f3a9d2f@app.fastmail.com>
In-Reply-To: <SJ0PR15MB46935068A5E9F9B4288FAB57D45A2@SJ0PR15MB4693.namprd15.prod.outlook.com>
References: <170807134367.25372.9131938145722079298@ietfa.amsl.com> <CANatvzyLJnZH9UHaSoMWbv20VhEtAzY7HqRHCSWt-O65f24uwQ@mail.gmail.com> <93FF52D7-53DD-4B72-A54F-EF952F7B5054@eissing.org> <SJ0PR15MB46935068A5E9F9B4288FAB57D45A2@SJ0PR15MB4693.namprd15.prod.outlook.com>
Date: Mon, 26 Feb 2024 16:17:26 +0000
From: Lucas Pardue <lucas@lucaspardue.com>
To: Roberto Peon <fenix@meta.com>, Stefan Eissing <stefan=40eissing.org@dmarc.ietf.org>, Kazuho Oku <kazuhooku@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="f702d7293bae4f46a5fca84036b3d866"
X-W3C-Hub-DKIM-Status: validation passed: (address=lucas@lucaspardue.com domain=lucaspardue.com), signature is good
X-W3C-Hub-DKIM-Status: validation passed: (address=lucas@lucaspardue.com domain=messagingengine.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, DMARC_MISSING=0.001, 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_DBL_BLOCKED_OPENDNS=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: pan.w3.org 1redfs-004P9B-0e fae69f23be20a79dc4b8cd9634dc9e4a
X-caa-id: 22cc8adbe3
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/63c9787e-3e76-4a47-80e3-ba4d7f3a9d2f@app.fastmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51842
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 Roberto,

On Mon, Feb 26, 2024, at 16:04, Roberto Peon wrote:
> From a functional point of view, when doing a mapping of H3 to any TCP (or TCP-like) thing, we need to answer the question:
> 
> How do we deal with the potential of deadlock because of TCP’s flow control conflicting with the “higher level” protocol’s without also allowing for OOMs?
> 
> Seems like it could be possible, but I don’t see an explanation.

Good point. Seems like HTTP/2 has the same problem, and gives some consideration text in Section 5.2.2 [1]. Do you think adding similar text to QUIC on streams covers it?

Cheers
Lucas

[1] - https://www.rfc-editor.org/rfc/rfc9113.html#name-appropriate-use-of-flow-con

> 
> -=R
>  
> *From: *QUIC <quic-bounces@ietf.org> on behalf of Stefan Eissing <stefan=40eissing.org@dmarc.ietf.org>
> *Date: *Friday, February 16, 2024 at 01:20
> *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>
> *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)
> !-------------------------------------------------------------------|
>   This Message Is From an External Sender
> 
> |-------------------------------------------------------------------!
> 
> 
> 
> > Am 16.02.2024 um 09:24 schrieb Kazuho Oku <kazuhooku@gmail.com>:
> > 
> > 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.
> 
> Interesting. This gives a much easier deployment path for HTTP/3 and extensions.
> 
> I have been reluctant to bring HTTP/3 to Apache httpd because the cost/benefit aspect is so unfavourable. I see no problem in bringing HTTP/3 over TLS into our server.
> 
> Cheers,
> Stefan
> 
> PS. We should probably not call this "TCP3".