Re: [quicwg/base-drafts] Add further guidance related to unidirectional stream TPs (#2612)

ianswett <> Fri, 12 April 2019 15:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8419012032D for <>; Fri, 12 Apr 2019 08:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.001
X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1klxi9Q8undB for <>; Fri, 12 Apr 2019 08:39:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5EB3912021F for <>; Fri, 12 Apr 2019 08:39:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=0cNcZmlDMAHJhwON5Z8OU0SEsA8=; b=i+KEqs6fKH89OMw/ PHt42Hr5RO86KuCQVR0wR4AvA57Al9furp7XiCK0c+SipL5kZ13rjHTMOk451y41 rfnzh+3ZbV1sDaUil+7eDp9BLEg13C5hUQIQICJpj9jL+CAM6rae9HvfqABXcOFT +HnLzY5RN8eYQRB3Me5wBdRwEhs=
Received: by with SMTP id filter1715p1mdw1-2767-5CB0B116-9 2019-04-12 15:39:02.176881271 +0000 UTC m=+84963.738582701
Received: from (unknown []) by (SG) with ESMTP id bmsJuJTXSgKNJf8vV8iRaQ for <>; Fri, 12 Apr 2019 15:39:02.163 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id 24A0A380075 for <>; Fri, 12 Apr 2019 08:39:02 -0700 (PDT)
Date: Fri, 12 Apr 2019 15:39:02 +0000
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2612/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Add further guidance related to unidirectional stream TPs (#2612)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cb0b11622ad8_2e23fbf032d45b831992e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak3DSMudLFbv2NWO0HkU5zGukvNta++oi8IAFM 2PaurfWivHENiPVwaBjyi68fY0WEZelzwRGGWY9CeEGV2x5q+8lvRCFwr132D15y6Ukwv6FuMWMIWz u5XGs8FHNccbRaOHwbh3Vc5FAUXESgYseJINw/ZMvY0ksnVwWO6b80XoaQ==
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Apr 2019 15:39:07 -0000

ianswett commented on this pull request.

> @@ -321,8 +321,19 @@ defined in this document: control streams ({{control-streams}}) and push streams
 ({{push-streams}}).  Other stream types can be defined by extensions to HTTP/3;
 see {{extensions}} for more details.
-Both clients and servers SHOULD send a value of three or greater for the QUIC
-transport parameter `initial_max_uni_streams`.
+The performance of HTTP/3 connections in the early phase of their lifetime is
+sensitive to the creation and exchange of data on unidirectional streams.
+Endpoints that set low values for the QUIC transport parameters
+`initial_max_uni_streams` and `initial_max_stream_data_uni` will increase the
+chance that the remote peer reaches the limit early. In particular, the value
+chosen for `initial_max_uni_streams` should consider that remote peers may wish
+to exercise reserved stream behaviour ({{stream-grease}}). Limits can be
+increased post handshake at the cost of additional RTT, for example by
+exchanging `STREAMS_BLOCKED` and `MAX_STREAMS` QUIC frames. To reduce the

The receiver should know when all the flow control credit is used(ie: it knows the current max and it knows the amount used in order to enforce limits), so when it gets to or close to 0, it should know the peer is unable to send.

In practice, the current text advises providing enough window for 2RTTs I believe, which is reasonably generous.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: