QUIC stream limits exposure to application mapping

Lucas Pardue <lucaspardue.24.7@gmail.com> Tue, 19 May 2020 17:17 UTC

Return-Path: <lucaspardue.24.7@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DAFFF3A09F2 for <quic@ietfa.amsl.com>; Tue, 19 May 2020 10:17:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.131
X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_BL=1.979, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 17QGcAs5lwr8 for <quic@ietfa.amsl.com>; Tue, 19 May 2020 10:17:37 -0700 (PDT)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811B93A0899 for <quic@ietf.org>; Tue, 19 May 2020 10:17:37 -0700 (PDT)
Received: by mail-wm1-x334.google.com with SMTP id m12so46722wmc.0 for <quic@ietf.org>; Tue, 19 May 2020 10:17:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=58GZco10Z1/OO1pnhC15KQ+Jz8LNNt3nOvjvdXr7vcI=; b=p+OJJW+uBXIFlE9IoeOzaXR+s1DR43QGTUVvTCKxznQxrbeXYfpl0AA9W6+LsYzFMb MIJCnLGXslg4040QSZoz3RPbUOmDnVJmUUL4G/cxnl6iGe5IjJjxuXBk6VM8UhzSYaet t7NBjDVpdbAUm5IXfsBR8BrAeJqk3hpn7/I8VyT2H+HmQKaFJAHORIIuUxzHt9q7dxVs /YhpXTAWufpiHf5oEGuREG/I/tMphY0+CbEV/pc9U941l2Wx589qSogOWA8KnDFeTI6k nJa27mB8hQYyg8Z13yesyliP4jG1z9fF1BA/WhzFCMzVs8DHtq8wEmAhcC6AXeE6yfXv qK/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=58GZco10Z1/OO1pnhC15KQ+Jz8LNNt3nOvjvdXr7vcI=; b=j2yJ9yUAPo+TgG2U0Ia/+zJgchlk/CkaunsV6bXqtQtRyBs1eNUQOIvbb4WxdDZTov lrjXbfPalrR/M+xgfpFop4AD1IrnKRK8/ehjwJeQLRz9r1IuVtj0yX0yVsyFHspoAyqg py03X23ITk0ZEyywrui/Ma0egSWAamXfKw6uRxF8YuC7QEnOhYUT1dZoZLjIbRwF5pt0 tmjgOKV/NCR9RjEURlBELIt/ZB+jNG3D4SMzbpRofapouaaSQ9K6AoDGoUv+gBe72OYz JocDxoPJQ3TfiYRmXtj3NTqZGQNq4gc3G8x/fzrZYNhJL9I5w1xKWPBnJQDX9nDKJD9w IdDQ==
X-Gm-Message-State: AOAM530OQkrljOoav+pY44MreVz7AWeEkZuBK04LVfR2xq7d6lSxOMn/ 29wqEa4Ir+PAETK5yHhMrORd12HXRTyXT5sHqmu/Ul6v
X-Google-Smtp-Source: ABdhPJw4u1Y9Sl+QJMCWCgTrThbLg4vEcaVdmRbLg7OSk8rwNlOma0/9hyoC0RoSAKiPTK+OZibHAqKYTCRRiZbAW7Y=
X-Received: by 2002:a1c:b0c8:: with SMTP id z191mr407764wme.165.1589908655275; Tue, 19 May 2020 10:17:35 -0700 (PDT)
MIME-Version: 1.0
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Tue, 19 May 2020 18:17:24 +0100
Message-ID: <CALGR9oYYWfyp+0V9qJkEKcHaycgo+zR1-xsNuMaAb2KxC1Ft0w@mail.gmail.com>
Subject: QUIC stream limits exposure to application mapping
To: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009f851b05a6037489"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/IcYK2YSHn6CENcNj0b3lZ18CfnA>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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, 19 May 2020 17:17:40 -0000

Hello folks,

During the HTTP interim meeting today [1] we came to talk a bit about QUIC
stream ID limits and how implementations might or might not expose this
property of the transport layer to an application mapping layer.

To abstract the technical discussion: we have an application-mapping
message that can be sent on a stream and it contains a reference to a
different stream by ID. In order to bound resource usage there is the
requirement "if the *other* stream ID exceeds the stream ID limit, receiver
MUST close the connection".

To implement the above requires the application mapping to have access to
the transport's maximum stream ID. This makes assumption about how
implementations do things and rightfully has been questioned.

HTTP/3 describes some resource usage considerations but makes it clear that
QUIC is responsible for managing a connection's concurrency. There is an
expectation that HTTP/3 can ask the transport to manage a concurrency limit
on it's behalf, but that otherwise it need no further input or feedback.

I'd like to understand what implementations actually do in practice, and
solicit the arguments against exposing the stream ID limits. I think this
could be useful for other application mapping documents that need to work
with transport primitives.


[1] Specifically, we were talking about HTTP/3 priorities and the
PRIORITY_UPDATE frame whic is sent on a Control stream and references
Request streams by ID.