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)

Watson Ladd <watsonbladd@gmail.com> Fri, 16 February 2024 22:59 UTC

Return-Path: <watsonbladd@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 9DE76C14F73E for <quic@ietfa.amsl.com>; Fri, 16 Feb 2024 14:59:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 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_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] 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 qq65bDgonC9o for <quic@ietfa.amsl.com>; Fri, 16 Feb 2024 14:59:41 -0800 (PST)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 36B8FC14F6A6 for <quic@ietf.org>; Fri, 16 Feb 2024 14:59:41 -0800 (PST)
Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-33ce8cbf465so1190844f8f.3 for <quic@ietf.org>; Fri, 16 Feb 2024 14:59:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708124379; x=1708729179; 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=xBHTI5ymjwcp0lWvfqUa3//szoSUyFhDfndIfiMGf+k=; b=dHTa1MrWQJO9hHnchSGXzfEeYw3TEX/UPMocCtxeMIRAQAoPde/J2LQg9hn108PXnf jBlezioO3HIuvY4YZrsB69rW136UUFJ3MpmUwxeFsy8xtsWT2WtAgeCmRO76mA0x1i01 6VW/1HJUpQTNrvxTBqSsqX6ZZXz9sUXjfLxuoEFnJs1eEyJ7hn8QiVOp7aH8/2F22w35 cqqKSgDbGYLP1Yxu4UsolMCMP/asHb3CJfPZwJ454CfC9h5LApOKHPS4pGvsFUVWwt3b RSPLGt3MUFLJ0+ji+s/nHY18JsRboBSZULHHo0YSS+7kOP3jeVslWhU76qbFL0VYNIZn OyfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708124379; x=1708729179; 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=xBHTI5ymjwcp0lWvfqUa3//szoSUyFhDfndIfiMGf+k=; b=s4OvcdFuliamirXpL/uN+SDjRDGZ4QmaNgGQ8bau3EzhDGMmEUawdkVXFzP+DQfyZX mnfWryKyuOVP/sX6DbG6N/Zj53m0LLdCOf/bktO7doYcx9egwO0Oxw5pKt9+jdW3M7r8 ltCgNw29mfk9lyR883HW6DD7lJNRljo7aWmdS7dryIbNbRyUjzqRoJOQfvbeFeXrIGQh 8Zbt6hAWTsjpKDoHsVd5iVCQVWQPi/NByxcMK+bf6/fz7ADMUPWBhmt88wetiW9EEXA8 PxthKLYfl4WhsBitk2LSoI5Z3HlGKYx9IYoagQ/UctEjkylRTx3YSBj9qKHDTVxA8fS7 iRSg==
X-Gm-Message-State: AOJu0YzqnM55oN9aUUKyqQkiKQepSgHLTHcGJ7ayMziMufIcaptQTsy8 h+zuRDV3/25Mbm9XIsEb4kIob8m1zQTw7ARLdQQE7RXm3FGrVSRC2KA8gFX2muwHGoto3eX0aRs reTkzWUbrKxZw8ryu5i/AQdOsSo0=
X-Google-Smtp-Source: AGHT+IEPl6kNXg4wKmu3/hu9xpEy7eHjJBTvR3IlA9VSJ7p7Irlm1q8lGnBYEu3Dhcz94G5GN0Krkl0bIjK3wyDzH5E=
X-Received: by 2002:a5d:6e8b:0:b0:33d:150a:307f with SMTP id k11-20020a5d6e8b000000b0033d150a307fmr2742215wrz.64.1708124379137; Fri, 16 Feb 2024 14:59:39 -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: Watson Ladd <watsonbladd@gmail.com>
Date: Fri, 16 Feb 2024 14:59:27 -0800
Message-ID: <CACsn0cmVFyLPnLr-snGy5ZWW=ndJ0bE4HriLgfrGjGRxSa16Lg@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: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/PktieV6UdIwd9EV1TK-KAzKhU9E>
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 22:59:41 -0000

On Fri, Feb 16, 2024 at 12:29 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:

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

I have some mild skepticism about this design. Each QUIC extension now
has to consider TCP transport, vs. each HTTP extension considering H2
or H3. However I think the necessary change isn't that much for QUIC
over TCP vs. H2/H3, unless the extension does a lot of the prohibited
things. You don't however get much improvement: H2's TCP related
limitations remain.

Is this need for a choice supposed to also apply to non-HTTP QUIC applications?

Sincerely,
Watson