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)

Kazuho Oku <kazuhooku@gmail.com> Sat, 17 February 2024 00:02 UTC

Return-Path: <kazuhooku@gmail.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 D527DC151063 for <quic@ietfa.amsl.com>; Fri, 16 Feb 2024 16:02:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, FREEMAIL_FROM=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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2NzGXaf_lAXJ for <quic@ietfa.amsl.com>; Fri, 16 Feb 2024 16:02:35 -0800 (PST)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 0652EC14F5FA for <quic@ietf.org>; Fri, 16 Feb 2024 16:02:35 -0800 (PST)
Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a3dfb2e03e7so93836266b.3 for <quic@ietf.org>; Fri, 16 Feb 2024 16:02:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708128153; x=1708732953; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8osjFmtX9ak4Tqe/vbeZINaKFfrq2KXmT2VrF9ERaaU=; b=Muu4E1oT8/aw+P/yQhC+2bhuROB3jbZGE8fuAIhyccWjdpg32M+h/u7S08CaqUP/U+ 8eoDTCvjDv/hjIFxdIohvpWdpFTkbVmYYGPRx2JCLD/K1f01U3249GtuOyJW76nfPAZu mNxpBlLlRGZ+82B+bFnSxxTKMHjFrfiA8I2pLebJ+KGYHepsRW/S7PXFpqgQPJs+n+qF oUMk4NB0xE1/pRx2T8ri5p/qlDV/2p4sthyQKGDgl3UQTg9YsTAVMRsbUkoGmr5WL9aF R51R3r+YDh08M9DZzKAJpNW9pRjJIZzgwGVjw+P432OEkCfv28a0JMJvnl9Fe955jE4e Cfsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708128153; x=1708732953; h=content-transfer-encoding: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=8osjFmtX9ak4Tqe/vbeZINaKFfrq2KXmT2VrF9ERaaU=; b=w2cs3MPo9c39wMxcQ4FVxpAZepyEYTUoaanyetlgotW2KQBo/ET9DkDtcomYgtWlf2 1T0kECMqe1MXrR72BiYkR4ZE5TBcC6kVeZKiaTixGUuGO5zyFI/ddpTdmIvURIj8IQji +UdGkxBDJn1tHaY9af69MWJHtDeTlHW3uSxqF8vzFhD4sz6SgFYUib/ZgIGwcvYd8P6y UW1EPvVNH6yTWwCcE0hRI68B11UiXpj3PBwiWmEW4kuXZuq8ZwCaTzytOUpOkfSqbI2c XpUyUc6ac8cpkRF+63A83DETJEhm0MZBfbGLTQX5T9AORBmLwv3Y4GQfvqa0e1gsW51b hrEA==
X-Gm-Message-State: AOJu0YzYsyLiNWrtZJkRjEDrOq0FfoxT7xhTD8GR3WLS+EHL/Ay/Y62y X0UktJdQSR8SKaukz9IDEcooc5RU+7TKba87g00H32VZejTM+GL16Od4FOPSzSZr+Q831tAi3JL A2ryO2t5X+K7Riy11odjnA6IybtE=
X-Google-Smtp-Source: AGHT+IGChNQ+C+xdiZVIvNmOl4wWuc1EwZMYd2Tvl3B8tyEzWLKULc4/xST3HZP9Mwua28hvzH4ExniPhwC7aaDBMTE=
X-Received: by 2002:a17:906:480d:b0:a3d:14ce:d95 with SMTP id w13-20020a170906480d00b00a3d14ce0d95mr4441950ejq.47.1708128153223; Fri, 16 Feb 2024 16:02:33 -0800 (PST)
MIME-Version: 1.0
References: <170807134367.25372.9131938145722079298@ietfa.amsl.com> <CANatvzyLJnZH9UHaSoMWbv20VhEtAzY7HqRHCSWt-O65f24uwQ@mail.gmail.com> <CAAZdMafuJfWmFkqOwvrWOEwtMfSRGfCpeZsUFqsFdaYmLhWbHw@mail.gmail.com>
In-Reply-To: <CAAZdMafuJfWmFkqOwvrWOEwtMfSRGfCpeZsUFqsFdaYmLhWbHw@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Sat, 17 Feb 2024 09:02:21 +0900
Message-ID: <CANatvzxsmXk99rFPYGvq-x6aL6bk4cmwWyw9VXbQ5F3FEnhOZA@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: Victor Vasiliev <vasilvv@google.com>
Cc: IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, Lucas Pardue <lucas@lucaspardue.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/KqSSxxwgYK13-coWYBYrOMLCByU>
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: Sat, 17 Feb 2024 00:02:38 -0000

2024年2月16日(金) 18:29 Victor Vasiliev <vasilvv@google.com>:
>
> 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.

Victor, thank you for your comments.

I concur.

Historically, we've operated under the assumption that H2 and H3 must
coexist. That has been the tone at HTTP WG. It was a logical choice
for WebTransport to start by defining its own way of conveying streams
atop HTTP/2. That work had to be done, I wholeheartedly appreciate the
efforts.

But now that QUIC has taken off, it might be the right time to explore
ways to convey QUIC over streams that extend beyond the current scope
of WebTransport over H2. This effort would benefit not only
WebTransport over H2 but also H3 and new application protocols being
developed on top of QUIC.

>
> 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



-- 
Kazuho Oku