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