Re: QUIC stream limits exposure to application mapping

Martin Duke <martin.h.duke@gmail.com> Tue, 19 May 2020 17:52 UTC

Return-Path: <martin.h.duke@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 E02713A0F8C for <quic@ietfa.amsl.com>; Tue, 19 May 2020 10:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUVSkh9L5y1B for <quic@ietfa.amsl.com>; Tue, 19 May 2020 10:52:37 -0700 (PDT)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 6E99B3A0F90 for <quic@ietf.org>; Tue, 19 May 2020 10:52:37 -0700 (PDT)
Received: by mail-il1-x12c.google.com with SMTP id b71so239917ilg.8 for <quic@ietf.org>; Tue, 19 May 2020 10:52:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iS9bmCOOI4xkDCs82fb2fI/6z/mlCECZXExcYm1fthM=; b=fwtOAII9T10G21dgYxwkFgva96w4HZegrArvMItWMKtOcmxuNk0bbWrG1BX/MaxQb7 c3U4zDasU94N9KiSMQPmuxEqZcfvJROMZzaYH73/k++lD9UL8hhQgUvfOEzPQXtlXG2F bgeMSwl4pn4qESzALjHKsmhYL3EL47t7wexkYOCb1aVjKuiNS6BxiUx2Nt9a3en0Obsx Y+w8W0wxBAfP4nK5HvbwKiiqy7dYFog2nNo2DxDc3qpp3PQ6MEYTPkO+zREfR1M2hNTp ZLqGdsRxdqUiX02O/cY9jVIvB3jO+IH1sgRnDwGC4W0CMimhbnY3LMHOdpP7IO4mJbX7 RQ0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iS9bmCOOI4xkDCs82fb2fI/6z/mlCECZXExcYm1fthM=; b=Qd9Z2PD7CSFEYyTsG1XGZNAcTYRHaM912j/tZKCYlHcFbrYLgFDyl0dZlYo+Hegsat CKrg4hFu2eEJTdMO4yUsPOYXpAJIq0Pk5UZjhY6xtCBWbdCW0rC083jyR3LI5VvvFrft 5GjNFSks4FgmxM9kA7Ss2bI1xRWekxb26r7gJO3ozgIOoYEBgmF1jSrecPntMsnHUG0C O9j0aPZ9vsXVWcJ3kFIMORUFK0nOeBorBv2Qs1wB9XCbBplKXOomw0kTAkbdJys/l0WM eaGnLpn6goWpsK+J3lGAjUWH27KTHM7rVeBGNVppyZWZxzDLlckF6KmUYm2aEkKFPShH lP3w==
X-Gm-Message-State: AOAM5306os2V03syIAivyc+GChBHfM2etQAHPC3h17WmHJNbi7Kb2I29 MicZtz/PTGkPI/fRhTfqTpmTigB4SNjcdRA0zsg=
X-Google-Smtp-Source: ABdhPJyR6+5vurI7UIE6Hwb6rZQhjef47DPxHMZYlU7zWQiw8K9r2HVkI8bw5+nv7sNOX4jZdutfOF2Qresw/fHnlic=
X-Received: by 2002:a05:6e02:965:: with SMTP id q5mr174409ilt.272.1589910756595; Tue, 19 May 2020 10:52:36 -0700 (PDT)
MIME-Version: 1.0
References: <CALGR9oYYWfyp+0V9qJkEKcHaycgo+zR1-xsNuMaAb2KxC1Ft0w@mail.gmail.com>
In-Reply-To: <CALGR9oYYWfyp+0V9qJkEKcHaycgo+zR1-xsNuMaAb2KxC1Ft0w@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 19 May 2020 10:52:25 -0700
Message-ID: <CAM4esxSihfc8h8BU8zs4Fi7+1Dp+Rn9ny5aYs9+vD99EjpXuAA@mail.gmail.com>
Subject: Re: QUIC stream limits exposure to application mapping
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000df1e1805a603f1e4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Myl1-4LdXYijk1a5yH4UUnq7Jdg>
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:52:39 -0000

We (F5) expose the max_stream_id for each type to the application. We also
have a stop_allowing_streams() API to enable things like GOAWAY.

IMO that's superior to buffering stream requests QUIC can't immediately
fulfill, or making the application poll again and again until QUIC accepts
a new stream request.

On Tue, May 19, 2020 at 10:17 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> 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.
>
> Cheers
> Lucas
>
> [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.
>