IETF Logo Mail Archive

Re: QMux outcomes from IETF 125

Martin Thomson <mt@lowentropy.net> Thu, 26 March 2026 04:14 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: quic@mail2.ietf.org
Delivered-To: quic@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 70308D18FD49 for <quic@mail2.ietf.org>; Wed, 25 Mar 2026 21:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b="kEao+LZg"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="sBemYuR4"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEWHP_jRdYiR for <quic@mail2.ietf.org>; Wed, 25 Mar 2026 21:14:25 -0700 (PDT)
Received: from fout-b8-smtp.messagingengine.com (fout-b8-smtp.messagingengine.com [202.12.124.151]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id F3AAAD18FD3E for <quic@ietf.org>; Wed, 25 Mar 2026 21:14:24 -0700 (PDT)
Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.stl.internal (Postfix) with ESMTP id 706671D00045; Thu, 26 Mar 2026 00:14:18 -0400 (EDT)
Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-04.internal (MEProxy); Thu, 26 Mar 2026 00:14:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm2; t=1774498458; x=1774584858; bh=dX8UK07+y4utld2POQhVsGQXOWQlignT q4tLgc5R7ng=; b=kEao+LZg2iL2oZtzJxniNbwtJwCSGqFnx/o6s0XeBUaHqzjv QEWGG9zRoniiUTwUIyNnexYlFl0Fjj3MNsYoo5GxASRIpMllZFamOIOYz5HbyM6d qQYHsimi341ps5G5WkGm1pd2TI8H+01NHE8GkKOu9Jvh9bTNiQE/avyKObD3rVWj nPT8KhWui4NGBg+dgQYJGtC8WLjdcb4HxUjEeB+//dHJCXpj0FtLL2jWC8Rk3k1t N6eFmJi/2hc1qU0Lwkb8LPSQqarGGhqYsnGnCfD17ILQ7XJbbj3+k9GhfPIq6HdV DenxjVswbw9h2t9ibRf5GTmC/z0mkVPAAI7HdQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1774498458; x= 1774584858; bh=dX8UK07+y4utld2POQhVsGQXOWQlignTq4tLgc5R7ng=; b=s BemYuR4DzGnISJXV4vdd5We0oWalPh947gFM1l92fxg5CNvjuwQwKIHpDU3wTWcY 2SXS9StrQQNTPw5tBZKupAnBsyANSanHLWL+QC5BMUrS76qjz7fsAuSxp1+NIv8p hx+aQfEHLE8jaTb7j8GfINTreNusvWmRASuAE1lUvb4aLD/afriHgS5UQRKN9RLt JNvNJj7SrLVulbVHsi6dWu47OAHm0p4SwBRSQzJa3BhGWQ2mB45RElYMMG6iTX02 WutH0/9rxfm7YaHUxBVvA7n+LQ2JS/EGvQO/8zRgtzSKARyNiItwjpFJm2qAZzYF ntogoUQJGtzghYeMIRjPw==
X-ME-Sender: <xms:mrLEafxEfauhtlA76j09hIJOEoPYbV-JBEfRiP6LXfHOWKU4Nx8yjQ> <xme:mrLEaSGbL4zV-mYPhBQ6tK3-BoDmtpdzjqI27VCyaN9XkoL633JiihSxYWUCxxlwV bAy6kQ8NzZ-F1ZEsaS9hFyTav9zqu1WxNFGmDmSesmbPvinHQUMRkY>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdefvdeifeeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtf frrghtthgvrhhnpedtvdetjeekgeelleelteekjefhteeivdekgfeujedvveduffehvdef tdevgefftdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvghtpdhnsggprhgtphhtthhopeegpdhmohgu vgepshhmthhpohhuthdprhgtphhtthhopehirghnshifvghtthepgedtghhoohhglhgvrd gtohhmsegumhgrrhgtrdhivghtfhdrohhrghdprhgtphhtthhopehkrgiiuhhhohhokhhu sehgmhgrihhlrdgtohhmpdhrtghpthhtohepqhhuihgtsehivghtfhdrohhrghdprhgtph htthhopehluhgtrghssehluhgtrghsphgrrhguuhgvrdgtohhm
X-ME-Proxy: <xmx:mrLEaeZQAMpa2CyilZQ4CFjqKzm4Hgd6DyeKOHVvRjKhPZWKW1GAQg> <xmx:mrLEafMj-Ss0k9Ju4UEXnEzRg38KB-ZW9b9KFlYCYWuvZY2ff4L6Tw> <xmx:mrLEaTbWpRo7zIhrMkzU0wmFAIoaQRaBCQFeNmzII5CWtNx9PcmLKA> <xmx:mrLEad0Gb_M-zWEkUBqeHNwLPokD23Ixcv3X1_wwUOzWQQkWaVOcqg> <xmx:mrLEaRsPXOk_n1sKdZE3Fvw4ib9-o9PqZKEpn6W2lrAX4diAKKKRjj34>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501) id EFA56780070; Thu, 26 Mar 2026 00:14:17 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: AbTwjgbOSQpN
Date: Thu, 26 Mar 2026 15:13:57 +1100
From: Martin Thomson <mt@lowentropy.net>
To: Kazuho Oku <kazuhooku@gmail.com>
Message-Id: <f20d8198-b096-4a73-8948-6b496466d7cd@betaapp.fastmail.com>
In-Reply-To: <CANatvzwwcu=-bmDqVJs38MVNYfsc4hSH-giJNXHKiwWy_XFj0A@mail.gmail.com>
References: <8f5c2ce6-e02e-4b72-8846-de822f3c1929@app.fastmail.com> <CAKcm_gN3zR_XxN6RF6eVv+86L5gXhZ31z2=tW4H=pZQa0-sX1w@mail.gmail.com> <df9cb59d-7af0-4d58-8eaf-8c6b2797d224@betaapp.fastmail.com> <CANatvzzX9sRorbH_NNZ+4Ywqf+y6S+o5=OvvJV=XB2BGN4ifYg@mail.gmail.com> <0b9d39aa-8619-460a-bf16-7cbeff50b57a@betaapp.fastmail.com> <CANatvzwubyeTcxmW4m4s50juwV5cGjVS95-RCu3Ec4JP3teu2Q@mail.gmail.com> <2e674bec-ef06-441e-84d2-20f11f004c4f@betaapp.fastmail.com> <CANatvzwwcu=-bmDqVJs38MVNYfsc4hSH-giJNXHKiwWy_XFj0A@mail.gmail.com>
Subject: Re: QMux outcomes from IETF 125
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-ID-Hash: LCIPGJQRHDDOE3Q6JTKKUFIHEEH7XEK6
X-Message-ID-Hash: LCIPGJQRHDDOE3Q6JTKKUFIHEEH7XEK6
X-MailFrom: mt@lowentropy.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-quic.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Lucas Pardue <lucas@lucaspardue.com>, quic@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/GwJplbWQ7AZAmEfHjV45K-aV5ZM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Owner: <mailto:quic-owner@ietf.org>
List-Post: <mailto:quic@ietf.org>
List-Subscribe: <mailto:quic-join@ietf.org>
List-Unsubscribe: <mailto:quic-leave@ietf.org>


On Wed, Mar 25, 2026, at 15:04, Kazuho Oku wrote:
>> In that case, if you have a 1:1:1:1 write:frame:QMux record:TLS record ratio, there is zero difference between the options.
>
> I disagree, unless you are proposing to impose a size limit on the 
> entire encoded STREAM frame, including the frame header bytes, which 
> would be an exotic design compared to having a size limit on the STREAM 
> frame payload.

I don't follow your argument.  I thought we'd agreed that writing a single STREAM frame produced identical bytes in the record or no record design, unless you are right at the boundaries where the varint encoding for the record is larger than the varint encoding for a STREAM frame length.  So how would the two designs be different regarding the TLS layer?

v2.46.0 | Report a Bug | By Email | System Status