From ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=ietf.org@listhub.w3.org Sun Feb 18 07:15:59 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 3252DC14F5F7 for ; Sun, 18 Feb 2024 07:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.856 X-Spam-Level: X-Spam-Status: No, score=-7.856 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_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="evx+2Fms"; dkim=pass (2048-bit key) header.d=w3.org header.b="ToOHcYGK"; dkim=pass (2048-bit key) header.d=lucaspardue.com header.b="v33swb0Y"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="Qk9ptKXZ" 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 aN_LtdmdxQ3c for ; Sun, 18 Feb 2024 07:15:54 -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 91E79C14E513 for ; Sun, 18 Feb 2024 07:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:Content-Type:To:From:Date:References:In-Reply-To:Message-Id: MIME-Version:Cc:Reply-To; bh=kZMVqXYAvGRhRbp2fy53OQBfHhf52Z+74HiW0GayPx4=; b= evx+2FmsOgv5VGp6Q7+WpJCcvoBxEDw4iaVMgY0KWuubOOpp7da6JF7lemDVr9jInAH/qU/RbQgHi gkLvikyRNUlPj/JSKJ9JoabniEg76JE4ftjTNC5FjnllyuJ1Vvd3pALD/MtvAxsPXGgd1Z9LJyhz5 Adj+rVg7ls0agHnm3jjf4dMV8Z7TuKQGrT3GLes1ObEoyb/Kza4Ot8dShEfE3ZKNp2I7SVV6LIb2c wvDcUY9hne2X3dnD+WFSxTW5CekGsrjaM4/DeNBURWPdprFq83ypNSP8cfyDrl61xxKFqgAbowjHI MMeC6DgRd8mKtN4BZW1j54OWgA+bTnGMqw==; Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1rbisR-00El5e-AD for ietf-http-wg-dist@listhub.w3.org; Sun, 18 Feb 2024 15:14:47 +0000 Resent-Date: Sun, 18 Feb 2024 15:14:47 +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 1rbisP-00El4g-2V for ietf-http-wg@listhub.w3.org; Sun, 18 Feb 2024 15:14:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Content-Type:Subject:To:From:Date:References:In-Reply-To:Message-Id: MIME-Version:Cc:Reply-To; bh=kZMVqXYAvGRhRbp2fy53OQBfHhf52Z+74HiW0GayPx4=; t=1708269285; x=1709133285; b=ToOHcYGK4fTlmRQ+sqn3pt0FNQ474sxIhj3EgFQe8IH7ZHT dD91oTgsDlsCBAyElv+uZGuHaWhntkdlrIJ+XJvx2fAy4+rsBtu7f27X7917IM/mymvUWlK1VHrSW PshUBcFW6JBaud7J/YErzV+BmxYWfnCYGqjP+qR+nXcB2rDCNonAE4vZftWdHvMARzfOzr964gbcT 7LJG9603pWdvRsshg+KrnaG+G3ZrBmuDbyIWtRKocMEGp6mU0HdTefYvIOR6nh9PldtaL1NOEGOWL zL4JK19T2kx2e1totiMbwxTRyVqV4qAh87SK6m2j3nU1gnhJm0qOga0iD/Z36IPg==; Received-SPF: pass (puck.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 puck.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rbisO-0014CP-02 for ietf-http-wg@w3.org; Sun, 18 Feb 2024 15:14:44 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfhigh.nyi.internal (Postfix) with ESMTP id A981511400A5; Sun, 18 Feb 2024 10:14:40 -0500 (EST) Received: from imap53 ([10.202.2.103]) by compute3.internal (MEProxy); Sun, 18 Feb 2024 10:14:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucaspardue.com; h=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=1708269280; x=1708355680; bh=kZMVqXYAvG RhRbp2fy53OQBfHhf52Z+74HiW0GayPx4=; b=v33swb0YLIV/AG2Dhgp1Ts9wpV 5NfcpEgxYC1tW/pjckQZmWQ4yzpySPe3QCFpRrSYgsp6nlm2gkzwbnnu9XltJk4a T935vh+OyUO8ictIg4J7IWjmiZTpl/6SI87C7BQG2UKGQirDGLl3MZGKh6zgfChG 4+h9JTml0wNDF0m7UtO3IcuwDX5GhN8a0F88oflW1bHvv+9IZ+y9pV5BaS5iTKZR nEBsj4jWUz2oNF/5jqoUYIbpUdj7f4sqUDLNcUGvmeaEKcmE+HIOVHvFDaGS4eyn AXB1sP39qMeeORRAUxipCzEgQhvW/6GFb16xaOZm9q5VB4LMfbZWgwxVmQEQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=1708269280; x=1708355680; bh=kZMVqXYAvGRhRbp2fy53OQBfHhf5 2Z+74HiW0GayPx4=; b=Qk9ptKXZT3hr68W7wGs5KZ3YnQ8hMW8LAi4JbLpin/eY kIj+sYfdBsWiBU/ncAPKtdjEh0rVIgBL33lxkjqEwlFT76nPJCxFKqQ5ClwJFoSc sChj1XYiXVWUy4g4FG6Ixp/Nmpz/l5//Db1rPjnnYCusUXi0EtgvkC+WEyURJhrN pnNsf8L5puG8I69xcjy9Y8wQX6UYvKyxpgjKiy0vZg6w8jkXlRYW2KA7DM5PDFe/ xLnf/FsBfuJZZ8iopnfBDYGh29YfRDLlBzlOzcw9q0mvz0gUkDEohFo3MBx88Hao y/L9nulOm2Kv6uLouzNN9ALBtNy4qoY0G83UyTZ3oA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvdeigdejiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfnfhutggr shcurfgrrhguuhgvfdcuoehluhgtrghssehluhgtrghsphgrrhguuhgvrdgtohhmqeenuc ggtffrrghtthgvrhhnpedvieelheekgeekieelhffhueffhffgteegvddvtdefvdekudet tdegleetlefhjeenucffohhmrghinhephhhtthhpvdgsvghtthgvrhdrohhnvgdptghloh huughflhgrrhgvrdgtohhmpdhivghtfhdrohhrghdphhhtthhpvddrsgihpdhhthhtphef figvtggrnhgtohhnshgvrhhvvggvnhgvrhhghidrsgihnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomheplhhutggrsheslhhutggrshhprghrughu vgdrtghomh X-ME-Proxy: Feedback-ID: i23b94938:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 560903640070; Sun, 18 Feb 2024 10:14:40 -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: <9971690d-50cb-4765-9133-b3497de07361@app.fastmail.com> In-Reply-To: References: <170807134367.25372.9131938145722079298@ietfa.amsl.com> Date: Sun, 18 Feb 2024 15:14:18 +0000 From: "Lucas Pardue" To: "Matt Mathis" , "IETF QUIC WG" , "HTTP Working Group" Content-Type: multipart/alternative; boundary=541d5c1233804df8a2d12fd5664e887c 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=-9.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_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_WL=-1 X-W3C-Scan-Sig: puck.w3.org 1rbisO-0014CP-02 f76c4f3a886d8962519bb2782a46e204 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: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/51799 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: --541d5c1233804df8a2d12fd5664e887c Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Matt, On Sun, Feb 18, 2024, at 14:36, Matt Mathis wrote: > What benefits would there be to http3 over TCP vs just downgrading? = I would bet that serializing http3 onto TCP forfeits (nearly) all of the= benefits of http3. From my perspective, the major benefit is for application implementers. = I'll use HTTP as the example but the proposal is not limited to that. Last summer, HTTP/2's stream concurrency model was abused to cause the l= argest layer 7 DDoS attacks recorded by several major operators. Mitigat= ions and safeguards were put in place by affected implementations. More = technical background is available from online sources, such as [1]. The realisations during that period was that HTTP/2's concurrency model = a) doesn't protect anything when the remote peer can drive the stream li= fecycle and continually renew its own credits and b) legitimate peers ha= ve a really hard time guessing what initial value of concurrency to use.= In reality, the best chance a server has of ensuring interoperability a= nd performance is to bound its minimum concurrency to 100. The blanket p= olicy doesn't exercise the capability as it was intended.=20 QUIC's stream concurrency model is slightly different, making it robust = to this form of attack. Primarily because the endpoint controls things w= ith explicit window increases via MAX_STREAMS frames.=20 At IETF 118 a side meeting was held to discuss ideas for making HTTP/2 b= etter. One proposal Martin Thomson and I wrote up was backporting QUIC's= concurrency design [2].=20 QUIC on streams is the opposite of trying to piecemeal backport features= to HTTP/2. A concrete benefit is that I could update my server to use H= TTP/3 over Streams and have a more unified codebase where I can focus ef= forts in development, testing and hardening. Right now, efforts are dupl= icated and split between these two very similar variants. I'm aware of greenfield projects that want to be QUIC first, and already= just speak HTTP/3. Theyd like to increase accessibily by providing a TC= P-based fallback thatvhas minimal complexity. They are a lot more enthus= iastic about HTTP/3 over Streams than having to pick HTTP/2 client and s= erver implementations and run through a whole new variant of implementat= ion and testing. Yes, there is HoL blocking. But that is livable. I'm aware of people ver= y interested in running QUIC over unix domain sockets or equivalent. HoL= doesn't matter there as long as the stream prioritaztion and frame sche= duling can be suitably tuned. > Fundamental issue: TCP has a 1 dimensional namespace for data (byte of= fset). QUIC has a 3 dimensional namespace for data (channel, message s= equence and byte offset). There is no reversible mapping* from QUIC to= TCP that preserves QUIC's native asynchrony. >=20 > * Except minion, which uses lots of kernel support to add a framing la= yer to break^H^H^H^H amend core TCP semantics. Minion would be much har= der to deploy than a lot of other options. Yes I agree. I thought the I-Ds were pretty clear about this constraint.= It might be nice to solve HoL blocking properly but I fear it would add= more complexity, which would push the balance too far away from the eas= e of deployment we were targeting.=20 Cheers Lucas [1] - https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-= ddos-attack [2] - https://datatracker.ietf.org/doc/draft-thomson-httpbis-h2-stream-l= imits/ >=20 > On Sat, Feb 17, 2024 at 1:03=E2=80=AFPM Hugo Landau wrote: >> On Sat, Feb 17, 2024 at 08:39:18AM +0900, Kazuho Oku wrote: >> > 2024=E5=B9=B42=E6=9C=8816=E6=97=A5(=E9=87=91) 18:00 Hugo Landau : >> > > >> > > > 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 eage= r 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, utili= zing QUIC on >> > > > Streams. >> > > > https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-http= 3-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 t= wo major >> > > > HTTP versions (HTTP/2 and HTTP/3), both actively used and exten= ded. This >> > > > might not be the situation that we want to be in. >> > > > >> > > > HTTP/2 is showing its age. We discussed its challenges at the I= ETF 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 betwee= n the HTTP >> > > > versions. >> > > > >> > > > Why are we doing this? >> > > > >> > > > Because HTTP/3 works only on QUIC. Given that UDP is not as uni= versally >> > > > accessible as TCP, we find ourselves in a position where we nee= d to >> > > > maintain and extend not only HTTP/3 but also HTTP/2 as a backst= op 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 o= n top of >> > > > TCP, and then use it to run HTTP/3 over TCP, do we still need t= o invest in >> > > > HTTP/2? >> > > > >> > > > Of course, HTTP/2 won=E2=80=99t disappear overnight. >> > > > >> > > > Yet, by making HTTP/3 more universally usable, we can at least = stop >> > > > extending HTTP/2. >> > > > >> > > > By focusing our new efforts solely on HTTP/3, we can conserve e= nergy. >> > > > >> > > > By making HTTP/3 universally accessible, and by having new exte= nsions >> > > > solely to HTTP/3, we can expect a shift of traffic towards HTTP= /3. >> > > > >> > > > This shift would reduce the necessity to modify our HTTP/2 stac= ks (we=E2=80=99d be >> > > > less concerned about performance issues), and provide us with a= better >> > > > chance to phase out HTTP/2 sooner. >> > > > >> > > > Some might argue that implementing a polyfill of QUIC comes wit= h its own >> > > > set of costs. However, it is my understanding that many QUIC st= acks already >> > > > have the capability to read QUIC frames other than from QUIC pa= ckets, >> > > > primarily for testing purposes. This suggests that the effort w= ould be more >> > > > about leveraging existing code paths rather than writing new co= de from >> > > > scratch. Furthermore, a QUIC polyfill would extend its benefits= beyond just >> > > > HTTP, by aiding other application protocols that aim to be buil= t on top of >> > > > QUIC, providing them accessibility over TCP. >> > > > >> > > > Please let us know what you think. Best regards, >> > > It's an interesting proposal. Looks fairly sensible. >> > > I could see a lot of other uses also for having a mapping of the = QUIC >> > > application-level semantics without QUIC itself, such as for diag= nostic >> > > use or intra-DC backhaul of incoming traffic. >> > > >> > > I question the utility of implicit length signalling. Unless ther= e's a >> > > real use for this (maybe there is and I'm just not seeing it) I w= ould >> > > probably just prohibit these encodings. The max_frame_size transp= ort >> > > parameter proposed here cannot be reduced below 16384. So you're = saving >> > > at most 3 bytes (to encode 16384) for every 16384 bytes. That wou= ld seem >> > > to yield an efficiency increase of 0.018%. For larger max_frame_s= ize >> > > values this obviously gets even smaller. >> > > >> > > Is there a rationale to supporting this I'm not seeing? >> > >> > Thank you for your comments! >> > >> > Regarding your question, in the initial draft, we attempted to limit >> > changes to the way frames are communicated, while preserving the fr= ame >> > encoding of QUIC v1 unchanged. The purpose of this approach is to >> > maximize code reuse between QUIC v1 and QUIC over Streams. >> > >> > For STREAM frames that lack length fields, we considered two option= s: >> > a) defining a method to deduce the length from another source, or >> > b) prohibiting the use of such frames. >> > >> > We opted for option (a) for consistency, under the assumption that = it >> > would not be more complex to implementations than (b). >> > >> > However, it was a narrow decision. I acknowledge that opting for (b) >> > would also be straightforward to implement, especially since STREAM >> > frames lacking length fields are identified by specific frame types >> > (namely, 0x08, 0x09, 0x0c, 0x0d), and considering we're already >> > restricting the use of certain QUIC v1 frames. >> Yeah. I would strongly support (b) without a very clear motivating use >> case otherwise. >=20 >=20 > -- > Thanks, > --MM-- > Evil is defined by mortals who think they know "The Truth" and use for= ce to apply it to others.=20 --541d5c1233804df8a2d12fd5664e887c Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Matt,

On Sun, Feb 18, 2024, at 14:36, Matt Mathis = wrote:
What benefits would there be to http3 over TCP vs just downgr= ading?   I would bet that serializing http3 onto TCP forfeits&= nbsp;(nearly) all of the benefits of http3.
=
From my perspective, the major benefit is for application implement= ers. I'll use HTTP as the example but the proposal is not limited to tha= t.

Last summer, HTTP/2's stream concurrency= model was abused to cause the largest layer 7 DDoS attacks recorded by = several major operators. Mitigations and safeguards were put in place by= affected implementations. More technical background is available from o= nline sources, such as [1].

The realisation= s during that period was that HTTP/2's concurrency model a) doesn't prot= ect anything when the remote peer can drive the stream lifecycle and con= tinually renew its own credits and b) legitimate peers have a really har= d time guessing what initial value of concurrency to use. In reality, th= e best chance a server has of ensuring interoperability and performance = is to bound its minimum concurrency to 100. The blanket policy doesn't e= xercise the capability as it was intended.

QUIC's stream concurrency model is slightly different, making it robust= to this form of attack. Primarily because the endpoint controls things = with explicit window increases via MAX_STREAMS frames.
At IETF 118 a side meeting was held to discuss ideas for ma= king HTTP/2 better. One proposal Martin Thomson and I wrote up was backp= orting QUIC's concurrency design [2]. 

QUIC on streams is the opposite of trying to piecemeal backport feature= s to HTTP/2. A concrete benefit is that I could update my server to use = HTTP/3 over Streams and have a more unified codebase where I can focus e= fforts in development, testing and hardening. Right now, efforts are dup= licated and split between these two very similar variants.

I'm aware of greenfield projects that want to be QUIC fi= rst, and already just speak HTTP/3. Theyd like to increase accessibily b= y providing a TCP-based fallback thatvhas minimal complexity. They are a= lot more enthusiastic about HTTP/3 over Streams than having to pick HTT= P/2 client and server implementations and run through a whole new varian= t of implementation and testing.

Yes, there= is HoL blocking. But that is livable. I'm aware of people very interest= ed in running QUIC over unix domain sockets or equivalent. HoL doesn't m= atter there as long as the stream prioritaztion and frame scheduling can= be suitably tuned.

Fundamental issue: TCP has= a 1 dimensional namespace for data (byte offset).   QUIC has = a 3 dimensional namespace for data (channel, message sequence and b= yte offset).   There is no reversible mapping* from QUIC to TC= P that preserves QUIC's native asynchrony.

= * Except minion, which uses lots of kernel support to add a framing= layer to break^H^H^H^H amend core TCP semantics.  Minion would be = much harder to deploy than a lot of other options.
<= /blockquote>
Yes I agree. I thought the I-Ds were pretty clear about= this constraint. It might be nice to solve HoL blocking properly but I = fear it would add more complexity, which would push the balance too far = away from the ease of deployment we were targeting. 
=
Cheers
Lucas


<= /div>

On Sat, Feb 17, 2024 at 1:03=E2=80=AFPM Hugo Landau <= hlandau@openssl= .org> wrote:
On Sat, Feb 17, 2024 at 08:39:18AM +0900= , Kazuho Oku wrote:
> 2024=E5=B9=B42=E6=9C=8816=E6=97=A5= (=E9=87=91) 18:00 Hugo Landau <hlandau@openssl.org>:
> ><= br>
> > > Hello QUIC and HTTP enthusiasts,
<= div>> > >
> > > We, Lucas and I, have su= bmitted two drafts aimed at broadening the reach of
> &= gt; > HTTP/3 - yes, making it available over TCP as well. We are eage= r to hear
> > > your thoughts on these:
=
> > >
> > > QUIC on Streams: A poly= fill for operating QUIC on top of TCP.
> >= >
> > > HTTP/3 on Streams: How to run HTTP/3 = unmodified over TCP, utilizing QUIC on
> > > Stre= ams.
> > >
> &= gt; > As the co-author of the two drafts, let me explain why we have = submitted
> > > these.
> > &g= t;
> > > The rationale behind our proposal is the= complexity of having two major
> > > HTTP versio= ns (HTTP/2 and HTTP/3), both actively used and extended. This
<= div>> > > 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 ex= tend HTTP/2, as seen
> > > with WebTransport. Web= Transport extends both HTTP/3 and HTTP/2, but it does
>= > > so differently for each, due to the inherent differences betw= een the HTTP
> > > versions.
> &= gt; >
> > > Why are we doing this?
> > >
> > > Because HTTP/3 works only= on QUIC. Given that UDP is not as universally
> > &= gt; accessible as TCP, we find ourselves in a position where we need to<= br>
> > > maintain and extend not only HTTP/3 but als= o HTTP/2 as a backstop protocol.
> > >
<= div>> > > This effort comes with its costs, which we have been = attempting to manage.
> > >
> &g= t; > 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
> > > HTT= P/2?
> > >
> > > Of course= , HTTP/2 won=E2=80=99t disappear overnight.
> > >=
> > > Yet, by making HTTP/3 more universally usa= ble, we can at least stop
> > > extending HTTP/2.=
> > >
> > > By focusing o= ur new efforts solely on HTTP/3, we can conserve energy.
&= gt; > >
> > > By making HTTP/3 universally = accessible, and by having new extensions
> > > so= lely to HTTP/3, we can expect a shift of traffic towards HTTP/3.
> > >
> > > This shift would redu= ce the necessity to modify our HTTP/2 stacks (we=E2=80=99d be
<= div>> > > less concerned about performance issues), and provide= us with a better
> > > chance to phase out HTTP/= 2 sooner.
> > >
> > > 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 capa= bility to read QUIC frames other than from QUIC packets,
&= gt; > > primarily for testing purposes. This suggests that the eff= ort would be more
> > > about leveraging existing= code paths rather than writing new code from
> > &g= t; scratch. Furthermore, a QUIC polyfill would extend its benefits beyon= d just
> > > HTTP, by aiding other application pr= otocols that aim to be built on top of
> > > QUIC= , providing them accessibility over TCP.
> > >
> > > Please let us know what you think. Best regar= ds,
> > It's an interesting proposal. Looks fairly s= ensible.
> > I could see a lot of other uses also fo= r having a mapping of the QUIC
> > application-level= semantics without QUIC itself, such as for diagnostic
>= ; > use or intra-DC backhaul of incoming traffic.
> = >
> > I question the utility of implicit length s= ignalling. Unless there's a
> > real use for this (m= aybe there is and I'm just not seeing it) I would
> >= ; probably just prohibit these encodings. The max_frame_size transport
> > parameter proposed here cannot be reduced below 1= 6384. So you're saving
> > at most 3 bytes (to encod= e 16384) for every 16384 bytes. That would seem
> > = to yield an efficiency increase of 0.018%. For larger max_frame_size
=
> > values this obviously gets even smaller.
<= div>> >
> > Is there a rationale to supporting= this I'm not seeing?
>
> Thank you fo= r your comments!
>
> Regarding your qu= estion, in the initial draft, we attempted to limit
> c= hanges to the way frames are communicated, while preserving the frame
> encoding of QUIC v1 unchanged. The purpose of this appr= oach is to
> maximize code reuse between QUIC v1 and QU= IC over Streams.
>
> For STREAM frames= that lack length fields, we considered two options:
> = a) defining a method to deduce the length from another source, or
> b) prohibiting the use of such frames.
>
> We opted for option (a) for consistency, under the ass= umption that it
> would not be more complex to implemen= tations than (b).
>
> However, it was = a narrow decision. I acknowledge that opting for (b)
> = would also be straightforward to implement, especially since STREAM
<= /div>
> frames lacking length fields are identified by specific f= rame types
> (namely, 0x08, 0x09, 0x0c, 0x0d), and cons= idering we're already
> restricting the use of certain = QUIC v1 frames.
Yeah. I would strongly support (b) without= a very clear motivating use
case otherwise.


--
Thanks,
--MM--
Evil is defined by mortals who think they know "The Truth" and use= force to apply it to others. 

--541d5c1233804df8a2d12fd5664e887c--