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)
Florentin Rochet <florentin.rochet@unamur.be> Tue, 20 February 2024 14:30 UTC
Return-Path: <florentin.rochet@unamur.be>
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 59C52C157931 for <quic@ietfa.amsl.com>; Tue, 20 Feb 2024 06:30:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 (1024-bit key) header.d=unamurbe.onmicrosoft.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 QLwm0IXZmIc2 for <quic@ietfa.amsl.com>; Tue, 20 Feb 2024 06:30:32 -0800 (PST)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2116.outbound.protection.outlook.com [40.107.22.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84E5C14F6FA for <quic@ietf.org>; Tue, 20 Feb 2024 06:30:30 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f5/EPhiFO0Qp57GnSVJcfuQ78Q3sW8XU6N9VC9a4CTeylabnzhNC4RgTfIou1xAORZ6EeXV8s/PHIM5p3eEXQbyxzkTgJyF6ek8I9d4g4CLXunRTM+bUbqtc57dgLA7ENyrUVywM1r2pj5nJldouFvMq3G61GgbJOqrvzcqlZmZG0hxzOn/oB80onmftqxENOCoIaGB2cq50P4bgmNRT5NO2BUclHu2SxSUTuWeZK+ryOdoeYUBXz3ngD0c+K98wZV/wORhkHiao/EfTpVYVibFOd6l5waB36AH8Aq/y9S5XvFRBmZXucZyOOQwPzKMofzD+wzK5nDhq0mmJYVgk3g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=W0OGJSK7Dfgs8qF82kD0+qzEFc0/pSYQl2Fx79HCutY=; b=U/jow6OWRh8Dm72MowYwDwT85lZD29JkxAqKHrJ0TCqD9n3KkJmJpzoi7FvxpjQRwb2yfzdInDYvI61jJ4bkRKFyFy+yfr9O1CkJfAAhBGvzoxRj9Ghd76aBm3KDsYG7nwbm4q4egN7jLgNVUGCMGbKrL4DGDfUe0oxZIK1KlBO6MKpKey9hdIwSJ55m8jM1vckaJ4t0ByrpU7vZnr4V/mpzYxnU6ADdXbQ8+cntiYMa0eZ9tlLSdQhwzfA66DXvYncd8S7KPHFP1DSgqv/hBMoARwDbUWiUC2kuY3AHhGr8yQcVMK98YgRDW4YSEaCV60xaxn120qtB1iproZhs6w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=unamur.be; dmarc=pass action=none header.from=unamur.be; dkim=pass header.d=unamur.be; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unamurbe.onmicrosoft.com; s=selector1-unamurbe-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W0OGJSK7Dfgs8qF82kD0+qzEFc0/pSYQl2Fx79HCutY=; b=gg+MpOkWIhTC3J6uulO6TieiLwkxkda40oUeShg3N8tOVvXMt24Kqb4bloIWGU2el3Qq8r+tHDCklOiyFf9Ty/UgHT8zteddnS7kvpHeIhn2MZG7n58b9hevuAejm0IvNU5ZnGjwPHv7hgKRZq3e2ELs9jqi8+tMH+R7DhQNv4s=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=unamur.be;
Received: from AS2PR07MB8953.eurprd07.prod.outlook.com (2603:10a6:20b:550::19) by DB9PR07MB7243.eurprd07.prod.outlook.com (2603:10a6:10:219::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7292.39; Tue, 20 Feb 2024 14:30:27 +0000
Received: from AS2PR07MB8953.eurprd07.prod.outlook.com ([fe80::59c:e294:e0d9:3899]) by AS2PR07MB8953.eurprd07.prod.outlook.com ([fe80::59c:e294:e0d9:3899%5]) with mapi id 15.20.7292.036; Tue, 20 Feb 2024 14:30:27 +0000
Content-Type: multipart/alternative; boundary="------------j5uKIgYfefN7DrdLpfG0Jswy"
Message-ID: <eebd79a1-51fb-4fdf-9f6d-af86cd2f2df0@unamur.be>
Date: Tue, 20 Feb 2024 15:30:25 +0100
User-Agent: Mozilla Thunderbird
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)
Content-Language: en-US
References: <170807134367.25372.9131938145722079298@ietfa.amsl.com> <CANatvzyLJnZH9UHaSoMWbv20VhEtAzY7HqRHCSWt-O65f24uwQ@mail.gmail.com>
From: Florentin Rochet <florentin.rochet@unamur.be>
To: quic@ietf.org
Cc: Maxime Piraux <maxime.piraux@uclouvain.be>, Hosam Elkoulak <hosam.elkoulak@unamur.be>, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
In-Reply-To: <CANatvzyLJnZH9UHaSoMWbv20VhEtAzY7HqRHCSWt-O65f24uwQ@mail.gmail.com>
X-ClientProxiedBy: FR2P281CA0054.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:93::8) To AS2PR07MB8953.eurprd07.prod.outlook.com (2603:10a6:20b:550::19)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS2PR07MB8953:EE_|DB9PR07MB7243:EE_
X-MS-Office365-Filtering-Correlation-Id: ce3aaf50-ac34-4af9-f2da-08dc32207b6d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: u4ayL1WfeYOsH4RTcR4EEAmoY99yymzkaD81D+LPsLjdhQGs9/e1HJCWskemhS5iRb6ZCLlS+vopKwZeNH6OjhVBJwGoESbYtNAbm0ipVZYY3vViJAoXb376gNPczbh19S9+ayHs3OD6Qpb1FDRsTiSnxVsbHyymPmQcVnz2xKK4h0qiEaxGyNejcIz9CmXzyD2Se/t7vl9Tm5SsS4eu5L3ENh2tMWpaeq5bo8VPpepIaxmOPS7FNfh3xgLuc0MfEEEgGX+QB3aS1PoxTVFF4ADrcjDddgGJzEyQvV1STW2TrdSojK1d/N7mpHEqupc3c019N4Al6dvNXMD90XbaqpUx6uXpOOPsFw/+NDa/9bYjJHvIvk3HgA+fstNe5/WY1BjOyG/matwPf+osbgHixqBLFRa7jOxT5YpXY88RtwAlS3zcW0x8s+kgKZknwPrTHWXPj8i966M1rD6Ym68OD9skMLz0KCPB+5NVnDvwZMP61RA+zZ8r3YAsNKMJ/LTTrrF56wv5q1YFI5yYzhF60PdlA/FXKsW+xeU+bJ9lc5RDh4XDQr6L7J+cczRcWCRE2N/GrCDNstpu6Az6w4AtfJLBKhVV5ooQVlBzOsh3igU=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS2PR07MB8953.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(3613699003); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: ai1ZDljuhlogSvRY6QqRE1QIFoJQHCBSgttB2FtA/ReeHlhNzhAwzFn5s6Tv6LypwEISza2H4F6tw+J5N5RiDGiEo64eIudWbKELgzoWWin2XK4AS3yDYkKvP0R0hQugRi7X51XEwM0rB4fLIe6Iff2zvxQbtrb9FN/DUxLSdl0I75bBFMAXcuyvSznqzOIPB9lo4S3DDPlLKHOILOgWH+tU8Jghlv7qa1XL4yyDH19VHToH/Vmb+USIpy5kP3Pw18N7W6vqwOzPw6tR2Zett43nH4qQAx0kmrwvcIAeRNWtJBJYGAVbqWHrk0n+gcuN4p1gHU6GPxcs/lule+0SQcqo01ndWDACdBMAbvWfKUW4SILyRtwE1RUNK1ZD9+mj8lNden+l8Jq1Jx2hd8x5GPm2sN4h31CuAYV/jyXBSEfqlN++nlQBc0I18WqzT8sBxUNX9s0NjJm9b7bVW/iNko6mvnnc+QEQcZ7f+o82QTU5zb+eHHrjxq1NjKA5si/8lTNXTU4gYp/aKVGwLrHFz6FGf9eNdjE7A3NNWE4YO4QHiUGp1kForKeJBSXyUp7TbcZijPIMGZb2c4kIWVpAhF60AjVAqRSM1wUDm+otqZT53RHBzKrxErV3lGBpgDfcT9UyFsrXtYXxyfWnqbL/dPL0fC9I3ALNx0JbxhlxDxUYPyUmvneiiGJCbtaCUDJtAHrDpFj38Ck+LICqf24c0Y55jc8vBuy277bXSkPkDqTJb2SvVOirJe9t3qw7FCovLwHoHqhgTngvcVyROz0wFCM6m3z1nvRg5he0W0J81gVwsK9VAblYkOXBCYe/5SnbbQLNlP2dTSu2mExbWQg2JamFPqdBtOfSrj9XZ6RdH0IaOVFQwLnmO7S7ao66GxsJt9G8P/78DMlPDyWl5vGdp0ncgEwJiX7zRkVBLQNCSgm2vrfxOe3KQA3LfQT/3vANSteCDXv7mOXZ6Aoe2K6XpTtOtqVqClXwvm70aNY9cUuSWMGx+NSG0I+KNtZGzhJXBPHJJhfM9JgYZAmcBYXpHyU/Oqiohtb7Zxt6QUe0hxSsuw5xhzPBEJ5KtarYLINbmgOB8Lk3dtw3C4Exi1fGUUC5uLJXjNNyGkCtgSbdFUrs72s5u9Z6hsW34rkfTOOWktH88thImfPEeol5q4WS59F0aVoI6e+ZJZEM0qO1hyM8klyPClhESQwbIBaCufTRA1VgxkFGxd+r2oFMztzwoHkgOSZMCCWY4OK4pv+cF+ioy25Di9KyoEcFf6qWTWkpfUfutBaru/FmdHtJIvkBWK29pw9uKDuHTg+MYuMWtt1Q6VQRYYCz0i5OJK8TwQ+82n2/ORWWIewLqn69Mfenx/g1TVLWvryHtwJHqnPlxsh0QxP5QzZfpkyR/A+TSczWAfPIsF/N3gnAGbqlhhiMizJ9AnCQC1A0IJh4R/gA2E+uuWCPdFi1NkBimJq5I9+AKyOnlepgUr9qFUXuyClCBD3ySZZLcXBR7EYu9Yi4h7MJM06pw64qf/EpSekqZEQZjQdUFujhM1Gvaody4nUxO9zFK72NQAhjC+8SCI1UeguWOE3oUd9EuE4JSxLxOY9WroOc7MesOs/RWa2eXXTp8Q==
X-OriginatorOrg: unamur.be
X-MS-Exchange-CrossTenant-Network-Message-Id: ce3aaf50-ac34-4af9-f2da-08dc32207b6d
X-MS-Exchange-CrossTenant-AuthSource: AS2PR07MB8953.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2024 14:30:27.1772 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5f31c5b4-f2e8-4772-8dd6-f268037b1eca
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: /NKENKZUxaO/Z9Ra8F/1gYcwaQVMIKoQqWHjE1DOpm42d/T51ExrZ5g3J8t0YWrHdT2zyXnBfvsucBnPlorkJElxEui51lG3A/DDDyrNV6w=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR07MB7243
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/4-HbjCqMlPTKz0nsCXWJ5t3j0TY>
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: Tue, 20 Feb 2024 14:30:36 -0000
Dear Kazuho, Lucas and HTTP/QUIC designers, We would like to attract your attention on the TCPLS design that answers several of your motivations: - Supports making HTTP/3 more universally usable, having the same semantic mapping than QUIC. - Would contribute to phase out HTTP/2, and bring more security to HTTP. - Minimal impact on QUIC implementations. TCPLS is a TLS1.3/TCP intertwined stack design offering the same benefits than QUIC (HoL blocking avoidance, migration) but with TCP instead of UDP, leading to higher efficiency, and likely smoother deployment (anywhere TLS 1.3 works, TCPLS should work too). There are a few documents covering TCPLS for those who are interested: - An APNIC blogpost with a 10,000 feets overview comparison to QUIC -- https://blog.apnic.net/2022/05/24/tcpls-modern-transport-services-with-tcp-and-tls/ - The original ACM CoNEXT'21 publication -- https://orbi.uliege.be/bitstream/2268/264667/1/paper.pdf - An IETF draft where the initial design matured, and continues to evolve -- https://datatracker.ietf.org/doc/draft-piraux-tcpls/ - An implementation of the TCPLS draft supporting version 02 by Maxime Piraux: https://github.com/mpiraux/rapido it seems that one of the key points of your proposal is to have limited impact on QUIC implementers, by stripping away QUIC of some of its features (migration, and HoL blocking avoidance), and conserving the remaining message formatting, with minor tweaks. That makes total sense to get this fast and working, however we also loose interesting features on the way. We have worked with Olivier Bonaventure and Maxime Piraux on some iterations of the TCPLS design during the last years. Some of the solutions that we found are probably also applicable to the problem that you want to tackle and we'd be happy to collaborate and discuss with you and the working group on these problems. We also have running code as an extension of picotls (rapido) and Hosam Elkoulak is working on an independent implementation in rust, and improvements of the current draft. One key question for this discussion: would future HTTP/3 services atop TCP be "ok" to loose the cool QUIC features (ie., multiplexing and connection migration) if they have to fallback to this HTTP/3 TCP solution? Best regards, Florentin Le 16/02/24 à 09:24, Kazuho Oku a écrit : > 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 > <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 > <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 > <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/ > <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 > <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 > <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/ > <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 > <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