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)
Matt Mathis <mattmathis@measurementlab.net> Sun, 18 February 2024 14:36 UTC
Return-Path: <mattmathis@measurementlab.net>
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 97A95C14F5F7 for <quic@ietfa.amsl.com>; Sun, 18 Feb 2024 06:36:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=measurementlab-net.20230601.gappssmtp.com
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 QgWg3HCDBwyj for <quic@ietfa.amsl.com>; Sun, 18 Feb 2024 06:36:47 -0800 (PST)
Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 A75D8C14E513 for <quic@ietf.org>; Sun, 18 Feb 2024 06:36:42 -0800 (PST)
Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-60837b7a8ddso1107287b3.3 for <quic@ietf.org>; Sun, 18 Feb 2024 06:36:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=measurementlab-net.20230601.gappssmtp.com; s=20230601; t=1708267001; x=1708871801; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=tyfu05CMXj8cHE45eFwyw+1W6z6kvZ6ShNhR1TVF3+w=; b=f+br/yTtXkqljI2YUB8tvi8WFl3nKusBuud1rHVi9edcYtlfh2qZz2QdDqGfiNObBO xxsoAVSUiTwf2cqkhWW0kUSLqTiRRv6GS16EUkp6m2Ufic4ihbySIKk9+ClbKUVhYOw7 sX8kk8scO0A2bVy52icLa9wyUZPExdiiBXhy8ZINI2Z9B95m5e1kJveFM1jzBVmjmF+J Dfi4Zt9BgtQXo9J9LRVJuZ62HMI4Qjmg9KrCSue6mphOC9Xjzp9O5vEseuJzcdhLS67U HuYjBRaQUFo6Zh89md5JAtBg2ZNXqbJUFEsZ740z7jxzrg3V5xa7fAyTeMJrONi3X4+G sLig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708267001; x=1708871801; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tyfu05CMXj8cHE45eFwyw+1W6z6kvZ6ShNhR1TVF3+w=; b=aW8lMdacSW7uq5s8ctMV/u6VvfiG0yxPgQl41BFBniX9sU/4rhTc2zJ4jEf+OYz+x6 WT+0ZUfGemLoozTf2IPBEF3BqOGJT9B3Nxq8VNd/iwUda65b3um2+upmb90xLYpAHobD 5ZkPJKmxUVxx3ue4CgwNOOa77k0e51hcCaaYFP6f3qhnGC+PIklfl6ug/nZ4i7yGhrf3 Rw+sHO9Sd+VG1vntgGeTU+uOWEOXkGrtnvX3AgOF0Qg+JrNTPKjyC8iNMsG+XcESnzfc HiR04UUzUGPA+TBwMGawMrTnaEIQuJJlKcigNhG6vu4tdw0UKygdUzLk6dq3JH5A5Usb j9Xg==
X-Gm-Message-State: AOJu0YzDVu1NohAUnYxxdMK1BbSuMBouEUYuTwAvWvhu0hKcKHsbdn6g 8EZyrXx+EuyrTuZIXkDuyt4TxkK7/oRHQCE36chcB7y+a3HCCVpp4ldRKRspRaQFYDVxKw+qxQt CkbaWd1pmaS2yTqpf4S1tjsOyMnhfNb49xc8mPiXShW9BOGCV+0Q=
X-Google-Smtp-Source: AGHT+IHLMBfJ4Dop1vd2+G7GD9oJaz4SGqh6u4ZK30B9Ojfe+JrlQmc4GmuQnmOFx9vbno1YYGb0r8Vnxf222/Ceky8=
X-Received: by 2002:a0d:eacb:0:b0:607:838b:a0c0 with SMTP id t194-20020a0deacb000000b00607838ba0c0mr11314121ywe.7.1708267000776; Sun, 18 Feb 2024 06:36:40 -0800 (PST)
MIME-Version: 1.0
References: <170807134367.25372.9131938145722079298@ietfa.amsl.com> <CANatvzyLJnZH9UHaSoMWbv20VhEtAzY7HqRHCSWt-O65f24uwQ@mail.gmail.com> <Zc8kDgXmkEku_61q@camelot.lhh.devever.net> <CANatvzwVpe2k9gjKFfkuudueDndS0Btgmx-_LWSajt=6K2MxMQ@mail.gmail.com> <ZdEfLiGmzKFZTurh@camelot.lhh.devever.net>
In-Reply-To: <ZdEfLiGmzKFZTurh@camelot.lhh.devever.net>
From: Matt Mathis <mattmathis@measurementlab.net>
Date: Sun, 18 Feb 2024 06:36:30 -0800
Message-ID: <CAEsRLK8A4G6A_hpmoTtBzo+7ARAE8k5b-EbgbEFWVgcz0cm5tA@mail.gmail.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)
To: IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000c369e10611a8e786"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ecKZ__nJ9YJaeI9ztrDiGnsnFGk>
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: Sun, 18 Feb 2024 14:36:51 -0000
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. Fundamental issue: TCP has a 1 dimensional namespace for data (byte offset). QUIC has a 3 dimensional namespace for data (channel, message sequence and byte offset). There is no reversible mapping* from QUIC to TCP 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. On Sat, Feb 17, 2024 at 1:03 PM Hugo Landau <hlandau@openssl.org> wrote: > On Sat, Feb 17, 2024 at 08:39:18AM +0900, Kazuho Oku wrote: > > 2024年2月16日(金) 18:00 Hugo Landau <hlandau@openssl.org>: > > > > > > > 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. > > > > > > > > By focusing our new efforts solely on HTTP/3, we can conserve energy. > > > > > > > > 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. > > > > > > > > This shift would reduce the necessity to modify our HTTP/2 stacks > (we’d 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 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 packets, > > > > primarily for testing purposes. This suggests that the effort would > be more > > > > about leveraging existing code paths rather than writing new code > 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. > > > > > > > > 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 diagnostic > > > use or intra-DC backhaul of incoming traffic. > > > > > > I question the utility of implicit length signalling. Unless there's a > > > real use for this (maybe 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 16384. So you're saving > > > at most 3 bytes (to encode 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. > > > > > > 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 frame > > 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 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 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. > > -- Thanks, --MM-- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others.
- 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