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

Lucas Pardue <> Fri, 12 April 2019 15:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D84012012E for <>; Fri, 12 Apr 2019 08:58:50 -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 tVWKKnc7x1LV for <>; Fri, 12 Apr 2019 08:58:47 -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 012CB1200E6 for <>; Fri, 12 Apr 2019 08:58:46 -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=CYiDasK5yDKsBVuz3Vt+IxGEue0=; b=w26HqW0GPAqfaXg8 ngjAvDQTNWSv6D81jPplS4+RBelPa5iiqqAZfaFrLK06jONinfSwqcc6YyoOUFtv WSekegVzNbr1wDd0TKUVF3qLCRchtZ3fv3RwrusNMWnLCfzBs77cjf+w9yhxrYeU AyMwJPfXH4hiOLpN++Xk5nQaxAQ=
Received: by with SMTP id filter1702p1mdw1-2091-5CB0B585-1C 2019-04-12 15:57:57.554054593 +0000 UTC m=+316815.882373118
Received: from (unknown []) by (SG) with ESMTP id 9D06cAUKScCKWWRKu6nVNA for <>; Fri, 12 Apr 2019 15:57:57.563 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id 7F07538006B for <>; Fri, 12 Apr 2019 08:57:57 -0700 (PDT)
Date: Fri, 12 Apr 2019 15:57:57 +0000
From: Lucas Pardue <>
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_5cb0b5857d75b_28c3fbf032d45b845572a"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak3UXCMZECD5EWOWHw1lPg2eDtsCLilJ/MNdan NZlqeq/LvC7nAbPc++1dIhsmudBTlDlVBKd/s1Dtwwcw7pfb3cRNwJq45Tt/voBtX9UMW66I0zfZMx 5uaFkCdp6hjfmAmMpiOByFS3E0ovNe5y2ye4nYPf4PAP0KeqyOBVywtNBHga/iFHolwBuReqGXtTmK 0=
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:58:50 -0000

LPardue 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

Sorry I should have been more specific, I was speaking about the number of uni streams not data. If the server gives the client initial uni streams value of 1, and the client uses up, what should the server do in the sense of upping the unidirectional stream limit? Not giving sufficient unidirectional streams will cause all sorts of annoying issues at the start of a H3 connection.

> 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.

The problem is that the flow control credit starts at 0 if not specified. So, without some sensible guidance for an initial value, if a remote peer initiates a new unidirectional stream, it then needs to wait for the the local peer to send a MAX_DATA of _some_ value. Again this is pretty naff when all you are trying to do is create a HTTP/3 Control stream.

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