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
>