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)
Victor Vasiliev <vasilvv@google.com> Fri, 16 February 2024 09:29 UTC
Return-Path: <vasilvv@google.com>
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 B4E98C14F694 for <quic@ietfa.amsl.com>; Fri, 16 Feb 2024 01:29:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.605
X-Spam-Level:
X-Spam-Status: No, score=-17.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 MM8wvbFDqyfc for <quic@ietfa.amsl.com>; Fri, 16 Feb 2024 01:29:01 -0800 (PST)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 C803EC14F68F for <quic@ietf.org>; Fri, 16 Feb 2024 01:29:01 -0800 (PST)
Received: by mail-pl1-x62e.google.com with SMTP id d9443c01a7336-1d5ce88b51cso110735ad.0 for <quic@ietf.org>; Fri, 16 Feb 2024 01:29:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708075741; x=1708680541; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=g7UlazkuQGOIb1mvS6M4RbJtc3+Nh4OoiajM3gGTlMM=; b=zLEneld7ePR6au/JAfr85Sjf0XyiKH7wVPG4UI7D82279gnqK3k+C3AzUCOXjfWOwr J1IX4UgMHKZSJRvf8V5Dooy8FqYiZcg9ZNZvAOujdYX71eGr+6x4t0KCc1J4wNfoW/BC EeYIvwKZOVLHRX9+M+l7BgBy+fGKW6glvW/Grn8JVNWMcwdlnNIlHfRL0CWLYEm26bvv Wh0t5UQyoLR7ocd1GnWffpPZQEMzxp4vp+7H0wFcMrcnoW+PYLowY3+P4+Db6C0Fr8Nn Bl86AEC1ayKE+3YOkYvCyFQQBDf8BWQ4mRFdmB4rz+CPInVMZIFB3mqh0nLGQUkBJHCd xTyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708075741; x=1708680541; h=cc: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=g7UlazkuQGOIb1mvS6M4RbJtc3+Nh4OoiajM3gGTlMM=; b=Z2OJAoOpjyc0Nt/7ZpNmimEqdETgBkym1/VozS7cc3wxfHxfJSj+Wvk7GcfY3Wjycl WUVjgtt/dQ4V+s3wh4grcteFl1uRbAN1Qv5Cq5J3WJV9a6uSeZ4lcYSU7GMOU+KeikWf /6lsx7893+IVshZhxQqdPF+lA4dV/Qj5jQ+ps+g3zPDw1V6VEyCC2A12+qrppwWQpqB+ CO5MApP1KPPfuaiuLpkw8xxUkeFpNWBpcAleFF0Ym8Vqy149QleFWwRxbbPeejaSHMCM I8DOxwaXQbD1ukWolIy265cUrZaL1UdF75dUibu8KeuGHUFhZCTQQ/zqI1ci4VnHvrR4 7aug==
X-Gm-Message-State: AOJu0Yz4TvGemoh2YMPA10sgYHFpDNwnOCw3hcRxoT2j7TqlH0/DI+gW JAid/6aPEZOHi/W/QKvRZEbe9gqN1IpcnXvTMCAferd2cQxzI5ewDIGYFQFnCdtgREYF/WOuSlU KAAE6z/VRSubAV+XYivIuVlWOrFxmfNc5jboTF2cAlqJS4qp+tIUo
X-Google-Smtp-Source: AGHT+IF29m1s9J+tAf9978O9PWraWg/iDO64AvU39HBJjgyetdvQizbvnHjixhl9AwMuL0c3eDtlSKGuYNdNZlpeqDA=
X-Received: by 2002:a17:902:e385:b0:1d9:a393:4a38 with SMTP id g5-20020a170902e38500b001d9a3934a38mr185868ple.26.1708075740640; Fri, 16 Feb 2024 01:29:00 -0800 (PST)
MIME-Version: 1.0
References: <170807134367.25372.9131938145722079298@ietfa.amsl.com> <CANatvzyLJnZH9UHaSoMWbv20VhEtAzY7HqRHCSWt-O65f24uwQ@mail.gmail.com>
In-Reply-To: <CANatvzyLJnZH9UHaSoMWbv20VhEtAzY7HqRHCSWt-O65f24uwQ@mail.gmail.com>
From: Victor Vasiliev <vasilvv@google.com>
Date: Fri, 16 Feb 2024 04:28:48 -0500
Message-ID: <CAAZdMafuJfWmFkqOwvrWOEwtMfSRGfCpeZsUFqsFdaYmLhWbHw@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: 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>
Content-Type: multipart/alternative; boundary="000000000000c5e17106117c5fbe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/eB2Yjq3nxwj4UOjLPtot3T11raA>
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: Fri, 16 Feb 2024 09:29:02 -0000
Hello Kazuho, The goals of draft-kazuho-quic-quic-on-streams appear to be very similar to draft-ietf-webtrans-http2, although the latter takes a different approach (it redefines all of the QUIC frames it needs manually rather than modifying existing QUIC frames). It would be nice if we had a single answer to the "I want to run QUIC over TCP" problem. Cheers, Victor. On Fri, Feb 16, 2024 at 3:25 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 > 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, > > ---------- Forwarded message --------- > From: <internet-drafts@ietf.org> > Date: 2024年2月16日(金) 17:15 > Subject: New Version Notification for > draft-kazuho-httpbis-http3-on-streams-00.txt > To: Kazuho Oku <kazuhooku@gmail.com>, Lucas Pardue <lucas@lucaspardue.com> > > > 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. > > 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 > > > Abstract: > > This document specifies how to use HTTP/3 on top of bi-directional, > byte-oriented streams such as TLS over TCP. > > Discussion Venues > > This note is to be removed before publishing as an RFC. > > 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/. > > Source for this draft and an issue tracker can be found at > https://github.com/kazuho/draft-kazuho-httpbis-http3-on-streams. > > > > The IETF Secretariat > > > > > -- > Kazuho Oku >
- 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