From ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=ietf.org@listhub.w3.org Sat Feb 17 08:41:56 2024 Return-Path: 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 8B608C14F5FB for ; Sat, 17 Feb 2024 08:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.855 X-Spam-Level: X-Spam-Status: No, score=-7.855 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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="D9z5p7Ge"; dkim=pass (2048-bit key) header.d=w3.org header.b="GYGCBShG"; dkim=pass (2048-bit key) header.d=gmail.com header.b="PFelhvw6" 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 cNM3pYQr8r8H for ; Sat, 17 Feb 2024 08:41:53 -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 63F65C14F60F for ; Sat, 17 Feb 2024 08:41:31 -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=vj1fTn+yZneGaCEFT8IQImBEp5y9m0zEXa+5Ks8XkQo=; b=D9z5p7Geob/tUdckiSf0HlnVQt ECVTfPp8bW7p/QqgwTj1ZAkE0LFPNloERxVJObtr6vSi3BZDmG+8NVrsaNTV+CGVJs9nq24KkIwqr Xs+OmrGoezZpJWtk4sd1RljTZz7mnhV4QeZgRHwcNq8OF/WaAkKh4iEYA426qoaAQhzS9ztjcUIXd ygHFxluhd54DUMcuryEwrM20F5QAT+P31RIt8mKVbVmZzBjzHnnkscEYgn4C4yGY9rnqE7U5J7cwl UX4Yn3AlzbRRSCeCTH/yGBeETu4OHSzpjcEucBCNRyXnQtJ6yfmvifKCnExLWM5naNv2soKFNZlmh 5m6lNSFQ==; Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1rbNkZ-00CyYC-WF for ietf-http-wg-dist@listhub.w3.org; Sat, 17 Feb 2024 16:41:16 +0000 Resent-Date: Sat, 17 Feb 2024 16:41:15 +0000 Resent-Message-Id: 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 ) id 1rbNkY-00CyX5-0X for ietf-http-wg@listhub.w3.org; Sat, 17 Feb 2024 16:41:14 +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=vj1fTn+yZneGaCEFT8IQImBEp5y9m0zEXa+5Ks8XkQo=; t=1708188073; x=1709052073; b=GYGCBShGdUX3TFejujhIIKs9oGYv0Sw+6gRQBGkP6k6qSzdNC9CM24GyvgmGhGnW+mso9cqQW6p wl+h6jvIPmiyVMGXtTSUGeF3zMHsSuI3f2bX+/LDuAo2dfFKeEC+WPyhpt1W0WwnRLJujI50riH1N mbklb1BPc97YkN9jgcGUcGaRXUStNkeTHoLlGD2ddOkdL2opvCIyyVQi6RY120gPbGb7ZD8MyaB7Q S62bnHvz6NuKaJ4Dn467hJfGJY6a+8tA3n3nsgWQyrbQ3GuWz8JUkvxbC+m5Vgf2MdO7MBC562yOt GSP3kgh+g4dvMaQaTlHYfC/shRVQaqoZuDuQ==; Received-SPF: pass (puck.w3.org: domain of gmail.com designates 2607:f8b0:4864:20::734 as permitted sender) client-ip=2607:f8b0:4864:20::734; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-qk1-x734.google.com; Received: from mail-qk1-x734.google.com ([2607:f8b0:4864:20::734]) by puck.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1rbNkX-000ngp-0W for ietf-http-wg@w3.org; Sat, 17 Feb 2024 16:41:13 +0000 Received: by mail-qk1-x734.google.com with SMTP id af79cd13be357-7838af983c1so233391885a.3 for ; Sat, 17 Feb 2024 08:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708188070; x=1708792870; darn=w3.org; h=subject:cc:to:from:date:references:in-reply-to:message-id :mime-version:user-agent:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=vj1fTn+yZneGaCEFT8IQImBEp5y9m0zEXa+5Ks8XkQo=; b=PFelhvw6EF6WDLH+9OCu3sK5qPJUCADjbFWKRVOhnnHNvaK5oZcMeNPauTXTYP2RPu A0+AoqsRceTUfAqHSr2ZgefKPTSmLILk2UJPQ2TFB20IVU3Q4ZCSGUoAYpEgDIAcGFvY 6kZrpAklfxS/rRrcpNxZK+WqWp7nqIqIrqu0ILmhJxBFYeofjEK+dmoasD+zvS5msBM5 s6W1vjTr1ap7zzXRtzokhaq6vn7Jk5GDf8asSYhpN/qFuGtUgxd8ETw5G/gxPNBwVG6r saaSiJv+UPwLekLZ4vcILuDWfCx1EBo46S04yKr8vZgtV1QLWugl3LuS1TQSb79t1yvD OFmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708188070; x=1708792870; h=subject:cc:to:from:date:references:in-reply-to:message-id :mime-version:user-agent:feedback-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vj1fTn+yZneGaCEFT8IQImBEp5y9m0zEXa+5Ks8XkQo=; b=CjFumMnS3fyn1eeItn+yghMI2rj1ecyzpuE3NYMd70B3FVASBFscFKpY3XCnZj3rDC Q9C8ehmefksc9HgpPxxRzICOfOC9tgTsdgnHME30ikwZ4XHSVZK1htGqZ3NYSDCwZxI7 I+rlz3Bj0VdcuByDNfsstYIep+ecM+cR6pMHPk0xzZVTNU/PEp7Jkydwge5sDy7ZQwQp d1ZSGe7uu4plfJ1KkXgWlWyj96L6Yuurn+K2JGnYGmFyc4UjiH8eZaFxhlMrvR8av1xs YI7UsNe+L88lU1OjoDRskeoSYK2R7ewRa06Z+eI49RHhvt+3X9JFz5utyBVtpg1zzN4n GmVg== X-Forwarded-Encrypted: i=1; AJvYcCVpVIY0SDgUYGVWFDo3JaxuPn6936uo51GiuNOOjb5exb86JQdekUOg3sdHRgJTfWxap4ZumYu7Bk8lUjQbmF96pqkh X-Gm-Message-State: AOJu0Ywqh63WOOtefr8Jh5zkCowRr0GRW+GbVtoEgZ7eHPz7r2oCCkwq 6PsKeX+sWW6R/fuGGHqPxlMD0RNesfGm2rmdN6jmGkOvEfzZNzRG X-Google-Smtp-Source: AGHT+IFbQ6c2JeuA22wYVxwnQhMiyY2/UDCZIIOwf4cLkxFtyaGNTKK+jGC0fu3yJpS6/Z54roJxyw== X-Received: by 2002:a05:620a:1036:b0:785:ac87:71c6 with SMTP id a22-20020a05620a103600b00785ac8771c6mr9317985qkk.21.1708188069614; Sat, 17 Feb 2024 08:41:09 -0800 (PST) Received: from fauth1-smtp.messagingengine.com (fauth1-smtp.messagingengine.com. [103.168.172.200]) by smtp.gmail.com with ESMTPSA id m20-20020a05620a221400b007872affb7d9sm947477qkh.45.2024.02.17.08.41.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 17 Feb 2024 08:41:09 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfauth.nyi.internal (Postfix) with ESMTP id B18AE1200043; Sat, 17 Feb 2024 11:41:08 -0500 (EST) Received: from imap53 ([10.202.2.103]) by compute3.internal (MEProxy); Sat, 17 Feb 2024 11:41:08 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvdeggdelvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesrgdtreerreerjeenucfhrhhomhepfdfnuhgt rghsucfrrghrughuvgdfuceolhhutggrshhprghrughuvgdrvdegrdejsehgmhgrihhlrd gtohhmqeenucggtffrrghtthgvrhhnpeekffelfeeiffehveejtefgheejfffhkeethfef udffvdefffffteethffhtdehgfenucffohhmrghinhepihgvthhfrdhorhhgpdhushgvnh higidrohhrghdphhhtthhpvddrsgihpdhhthhtpheffigvtggrnhgtohhnshgvrhhvvggv nhgvrhhghidrsgihnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomheplhhutggrshdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudeg gedtheegvdektddqfedtheeigeduhedvqdhluhgtrghsphgrrhguuhgvrddvgedrjeeppe hgmhgrihhlrdgtohhmsehluhgtrghsphgrrhguuhgvrdgtohhm X-ME-Proxy: Feedback-ID: i2dd14938:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 41072364006F; Sat, 17 Feb 2024 11:41:08 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61 MIME-Version: 1.0 Message-Id: <939e22d5-1707-4964-9f59-0dea39feebdc@app.fastmail.com> In-Reply-To: <078A16AD-9824-41B8-935D-0E4760FF1E22@ifi.uio.no> References: <170807134367.25372.9131938145722079298@ietfa.amsl.com> <078A16AD-9824-41B8-935D-0E4760FF1E22@ifi.uio.no> Date: Sat, 17 Feb 2024 16:40:46 +0000 From: "Lucas Pardue" To: "Michael Welzl" , "Kazuho Oku" Cc: "IETF QUIC WG" , "HTTP Working Group" Content-Type: multipart/alternative; boundary=386d48ba487a4054902b5ac0cd79eb6b X-W3C-Hub-DKIM-Status: validation passed: (address=lucaspardue.24.7@gmail.com domain=gmail.com), signature is good X-W3C-Hub-Spam-Status: No, score=-9.9 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_PASS=-0.001, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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_IRA=-1, W3C_WL=-1 X-W3C-Scan-Sig: puck.w3.org 1rbNkX-000ngp-0W a81c8c385532328e03a7de09072142d5 X-Original-To: ietf-http-wg@w3.org Subject: QUIC on streams compared to Minion (was 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: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/51794 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --386d48ba487a4054902b5ac0cd79eb6b Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Michael, On Sat, Feb 17, 2024, at 11:30, Michael Welzl wrote: > Hi, >=20 > QUIC over TCP=E2=80=A6 I hope that the people doing this are aware of = the old work on Minion? If not, see: > https://datatracker.ietf.org/doc/html/draft-iyengar-minion-protocol-02 > https://datatracker.ietf.org/doc/html/draft-iyengar-minion-concept-02 > https://www.usenix.org/conference/nsdi12/technical-sessions/presentati= on/nowlan >=20 > IIRC, the original Minion idea was to introduce a marker in the bytest= ream, but the later development (perhaps captured in the drafts above?) = worked off the principle that protocols above TCP already have these kin= ds of markers anyway - i.e., it doesn=E2=80=99t even need a change to th= e wire protocol, it=E2=80=99s just a =E2=80=9Cvertical=E2=80=9D change a= bout how to talk to the TCP buffer below. >=20 > Considering this, it seems almost silly to me to ignore this and map Q= UIC over TCP when streams can so nicely be implemented via TCP too, just= by =E2=80=9Cbreaking=E2=80=9D the TCP API =E2=80=9Ccontract". >=20 > My apologies if this is already a part of the plan - I just wanted to = point out this work because at this point, it=E2=80=99s old and might ha= ve been forgotten - yet it seems to fit the idea of mapping QUIC over TC= P like a glove. I'm aware of minion but haven't looked at it in a long while, thanks for= the reminder. I read over it very briefly and I intend to spend more ti= me digesting.=20 However, my intial understanding is that minion has a hard requirement o= n DTLS, is that correct?=20 Part of the motivation of QUIC on streams, as pointed at in the draft, i= s to address a concrete problem in HTTP/2 stream limits. There are propo= sals for how to fix HTTP/2 itself but some of that effort could be inves= ted in swapping over to HTTP/3 using QUIC on streams. Whether that would= be successful depends on the change complexity matrix. It's the authors view that many clients and servers already support HTTP= /2 over TLS and HTTP/3 (native QUIC) simultaneously, meaning the complex= ity of adding HTTP/3 over QUIC over TLS is minimized. Mostly because QUI= C implementations would need minor tweaks only. As an implementer (not a= uthor hat), the requirement to use DTLS would already start to be a put = off for me in the above scenario.=20 Can a minion-style (RE)COBS approach could be used with TLS? If so, what= benefits would that bring over the current proposal? HTTP/2 is already subject to TCP Head of Line Blocking. Maybe it could b= e nice to design a replacement that can fix that using TLS too. However,= if I understand the minion protocol design (a big if, I'm happy to be c= orrected), it only supports 4 reorderings. Furthermore, since the "booke= nds" are in the plaintext stream, it seems trivial for an on-path attack= er to interfere with them, opening up a new suite of security issues. Cheers Lucas >=20 > Cheers, > Michael >=20 >=20 >=20 >> On Feb 16, 2024, at 9:24 AM, Kazuho Oku wrote: >>=20 >> Hello QUIC and HTTP enthusiasts, >>=20 >> We, Lucas and I, have submitted two drafts aimed at broadening the re= ach of HTTP/3 - yes, making it available over TCP as well. We are eager = to hear your thoughts on these: >>=20 >> QUIC on Streams: A polyfill for operating QUIC on top of TCP. >> https://datatracker.ietf.org/doc/html/draft-kazuho-quic-quic-on-strea= ms >>=20 >> HTTP/3 on Streams: How to run HTTP/3 unmodified over TCP, utilizing Q= UIC on Streams. >> https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-http3-on-s= treams >>=20 >> As the co-author of the two drafts, let me explain why we have submit= ted these. >>=20 >> The rationale behind our proposal is the complexity of having two maj= or HTTP versions (HTTP/2 and HTTP/3), both actively used and extended. T= his might not be the situation that we want to be in. >>=20 >> HTTP/2 is showing its age. We discussed its challenges at the IETF 11= 8 side meeting in Prague. >>=20 >> Despite these challenges, we are still trying to extend HTTP/2, as se= en with WebTransport. WebTransport extends both HTTP/3 and HTTP/2, but i= t does so differently for each, due to the inherent differences between = the HTTP versions. >>=20 >> Why are we doing this? >>=20 >> Because HTTP/3 works only on QUIC. Given that UDP is not as universal= ly accessible as TCP, we find ourselves in a position where we need to m= aintain and extend not only HTTP/3 but also HTTP/2 as a backstop protoco= l. >>=20 >> This effort comes with its costs, which we have been attempting to ma= nage. >>=20 >> 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 inve= st in HTTP/2? >>=20 >> Of course, HTTP/2 won=E2=80=99t disappear overnight. >>=20 >> Yet, by making HTTP/3 more universally usable, we can at least stop e= xtending HTTP/2. >>=20 >> By focusing our new efforts solely on HTTP/3, we can conserve energy. >>=20 >> By making HTTP/3 universally accessible, and by having new extensions= solely to HTTP/3, we can expect a shift of traffic towards HTTP/3. >>=20 >> This shift would reduce the necessity to modify our HTTP/2 stacks (we= =E2=80=99d be less concerned about performance issues), and provide us w= ith a better chance to phase out HTTP/2 sooner. >>=20 >> Some might argue that implementing a polyfill of QUIC comes with its = own set of costs. However, it is my understanding that many QUIC stacks = already have the capability to read QUIC frames other than from QUIC pac= kets, primarily for testing purposes. This suggests that the effort woul= d be more about leveraging existing code paths rather than writing new c= ode from scratch. Furthermore, a QUIC polyfill would extend its benefits= beyond just HTTP, by aiding other application protocols that aim to be = built on top of QUIC, providing them accessibility over TCP. >>=20 >> Please let us know what you think. Best regards, >>=20 >> ---------- Forwarded message --------- >> From: >> Date: 2024=E5=B9=B42=E6=9C=8816=E6=97=A5(=E9=87=91) 17:15 >> Subject: New Version Notification for draft-kazuho-httpbis-http3-on-s= treams-00.txt >> To: Kazuho Oku , Lucas Pardue >>=20 >>=20 >> A new version of Internet-Draft draft-kazuho-httpbis-http3-on-streams= -00.txt >> has been successfully submitted by Kazuho Oku and posted to the >> IETF repository. >>=20 >> Name: draft-kazuho-httpbis-http3-on-streams >> Revision: 00 >> Title: HTTP/3 on Streams >> Date: 2024-02-16 >> Group: Individual Submission >> Pages: 5 >> URL: https://www.ietf.org/archive/id/draft-kazuho-httpbis-http3-= on-streams-00.txt >> Status: https://datatracker.ietf.org/doc/draft-kazuho-httpbis-http3= -on-streams/ >> HTML: https://www.ietf.org/archive/id/draft-kazuho-httpbis-http3-= on-streams-00.html >> HTMLized: https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-= http3-on-streams >>=20 >>=20 >> Abstract: >>=20 >> This document specifies how to use HTTP/3 on top of bi-directional, >> byte-oriented streams such as TLS over TCP. >>=20 >> Discussion Venues >>=20 >> This note is to be removed before publishing as an RFC. >>=20 >> Discussion of this document takes place on the HTTP Working Group >> mailing list (ietf-http-wg@w3.org), which is archived at >> https://lists.w3.org/Archives/Public/ietf-http-wg/. >>=20 >> Source for this draft and an issue tracker can be found at >> https://github.com/kazuho/draft-kazuho-httpbis-http3-on-streams. >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >>=20 >> --=20 >> Kazuho Oku --386d48ba487a4054902b5ac0cd79eb6b Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Michael,
=

On Sat, Feb 17, 2024, at 11:30, Michael Welzl = wrote:
Hi,

QUIC over TCP=E2=80=A6 I hope that the people doing this = are aware of the old work on Minion?   If not, see:
https://datatracker.ietf.org/doc/html/draft-iyengar= -minion-concept-02
https://www.usenix.org/conference/nsdi12/technical-sessions= /presentation/nowlan

IIRC, the original Minion idea was to introduce a marker in th= e bytestream, but the later development (perhaps captured in the drafts = above?) worked off the principle that protocols above TCP already have t= hese kinds of markers anyway - i.e., it doesn=E2=80=99t even need a chan= ge to the wire protocol, it=E2=80=99s just a =E2=80=9Cvertical=E2=80=9D = change about how to talk to the TCP buffer below.

Considering this, it seems almost sil= ly to me to ignore this and map QUIC over TCP when streams can so nicely= be implemented via TCP too, just by =E2=80=9Cbreaking=E2=80=9D the TCP = API =E2=80=9Ccontract".

My apologies if this is already a part of the plan - I just wan= ted to point out this work because at this point, it=E2=80=99s old and m= ight have been forgotten - yet it seems to fit the idea of mapping QUIC = over TCP like a glove.

<= div>I'm aware of minion but haven't looked at it in a long while, thanks= for the reminder. I read over it very briefly and I intend to spend mor= e time digesting.

However, my intial understanding is that minio= n has a hard requirement on DTLS, is that correct? 

<= /div>
Part of the motivation of QUIC on streams, as pointed at in th= e draft, is to address a concrete problem in HTTP/2 stream limits. There= are proposals for how to fix HTTP/2 itself but some of that effort coul= d be invested in swapping over to HTTP/3 using QUIC on streams. Whether = that would be successful depends on the change complexity matrix.

It's the authors view that many clients and serv= ers already support HTTP/2 over TLS and HTTP/3 (native QUIC) simultaneou= sly, meaning the complexity of adding HTTP/3 over QUIC over TLS is minim= ized. Mostly because QUIC implementations would need minor tweaks only. = As an implementer (not author hat), the requirement to use DTLS would al= ready start to be a put off for me in the above scenario.

Can a minion-style (RE)COBS approach could be used with = TLS? If so, what benefits would that bring over the current proposal?

HTTP/2 is already subject to TCP Head of Line= Blocking. Maybe it could be nice to design a replacement that can fix t= hat using TLS too. However, if I understand the minion protocol design (= a big if, I'm happy to be corrected), it only supports 4 reorderings. Fu= rthermore, since the "bookends" are in the plaintext stream, it seems tr= ivial for an on-path attacker to interfere with them, opening up a new s= uite of security issues.

Cheers
Lucas


Cheers,
Mi= chael


=

On Feb 16, 2024, at 9:24 AM, Kazuho Oku <kazuhooku@gmail.com> wrote:=

Hello QUIC and HTTP enthusiasts,

We= , Lucas and I, have submitted two drafts aimed at broadening the reach o= f HTTP/3 - yes, making it available over TCP as well. We are eager to he= ar your thoughts on these:

QUIC on Streams:= A polyfill for operating QUIC on top of TCP.

HTTP/3 on Streams: How to= run HTTP/3 unmodified over TCP, utilizing QUIC on Streams.
https://datatracker.ietf.org/doc/html/dr= aft-kazuho-httpbis-http3-on-streams

As = the co-author of the two drafts, let me explain why we have submitted th= ese.

The rationale behind our proposal is t= he complexity of having two major HTTP versions (HTTP/2 and HTTP/3), bot= h actively used and extended. This might not be the situation that we wa= nt 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 e= xtend 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 d= ifferences between the HTTP versions.

Why a= re we doing this?

Because HTTP/3 works only= on QUIC. Given that UDP is not as universally accessible as TCP, we fin= d ourselves in a position where we need to maintain and extend not only = HTTP/3 but also HTTP/2 as a backstop protocol.

<= div>This effort comes with its costs, which we have been attempting to m= anage.

However, if we could create a polyfi= ll for QUIC that operates on top of TCP, and then use it to run HTTP/3 o= ver TCP, do we still need to invest in HTTP/2?

<= div>Of course, HTTP/2 won=E2=80=99t disappear overnight.
<= br>
Yet, by making HTTP/3 more universally usable, we can at l= east stop extending HTTP/2.

By focusing our= new efforts solely on HTTP/3, we can conserve energy.
By making HTTP/3 universally accessible, and by having new e= xtensions solely to HTTP/3, we can expect a shift of traffic towards HTT= P/3.

This shift would reduce the necessity = to modify our HTTP/2 stacks (we=E2=80=99d be less concerned about perfor= mance issues), and provide us with a better chance to phase out HTTP/2 s= ooner.

Some might argue that implementing a= polyfill of QUIC comes with its own set of costs. However, it is my und= erstanding that many QUIC stacks already have the capability to read QUI= C frames other than from QUIC packets, primarily for testing purposes. T= his suggests that the effort would be more about leveraging existing cod= e paths rather than writing new code from scratch. Furthermore, a QUIC p= olyfill would extend its benefits beyond just HTTP, by aiding other appl= ication protocols that aim to be built on top of QUIC, providing them ac= cessibility over TCP.

Please let us know wh= at you think. Best regards,

---------- Forw= arded message ---------
From: <internet-drafts@ietf.org>
Date: 2024=E5=B9=B42=E6=9C=8816=E6=97=A5(=E9=87=91) 17:15
Subject: New Version Notification for draft-kazuho-httpbis-http= 3-on-streams-00.txt
To: Kazuho Oku <kazuhooku@gmail.com>, Lucas Par= due <lucas@luc= aspardue.com>


A new v= ersion of Internet-Draft draft-kazuho-httpbis-http3-on-streams-00.txt
has been successfully submitted by Kazuho Oku and posted to = the
IETF repository.

Name: &n= bsp;   draft-kazuho-httpbis-http3-on-streams
Revision= : 00
Title:    HTTP/3 on Streams
D= ate:     2024-02-16
Group:    Individu= al Submission
Pages:    5


<= /div>
Abstract:

   This docum= ent specifies how to use HTTP/3 on top of bi-directional,
=    byte-oriented streams such as TLS over TCP.
<= br>
Discussion Venues

  &nbs= p;This note is to be removed before publishing as an RFC.
=
   Discussion of this document takes place on t= he HTTP Working Group
   mailing list (ietf-http-wg@w3.org), whi= ch is archived at

  &n= bsp;Source for this draft and an issue tracker can be found at
=


=

The IETF Secretariat



--
Kazuho Oku<= br>
--386d48ba487a4054902b5ac0cd79eb6b--