Re: [quicwg/base-drafts] Allow not creating QPACK codec streams (#2529)

Mike Bishop <> Tue, 30 April 2019 18:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC18512036C for <>; Tue, 30 Apr 2019 11:41:57 -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 Qsfm4Ye3VJz2 for <>; Tue, 30 Apr 2019 11:41:55 -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 BD88E120330 for <>; Tue, 30 Apr 2019 11:41:54 -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=5vXC+TVvc6iczr+NUWEKxmJn+jM=; b=csTM9O77AIXD5nTT c7+CeUKKGLhitNn2OuB2Kk9NSGYNMZrbBTEmCVVfFP73e6ibrrRsRK829sTIi64V 7bOD4fSW8FUMXdDseS7Jzwc0SHTzW9LnsDC2Z1b+bIY8xWyRL6Sk947fxQjwfmUH Vf8NvlF+cLWMzLNcPbbtOR+pCrg=
Received: by with SMTP id filter1841p1mdw1-32704-5CC896E2-D 2019-04-30 18:41:38.177038216 +0000 UTC m=+420838.045854117
Received: from (unknown []) by (SG) with ESMTP id KxUi2NBlQYedhaqtVWsDLQ for <>; Tue, 30 Apr 2019 18:41:38.185 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id 23A9FC0C73 for <>; Tue, 30 Apr 2019 11:41:38 -0700 (PDT)
Date: Tue, 30 Apr 2019 18:41:38 +0000
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2529/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Allow not creating QPACK codec streams (#2529)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cc896e221ecb_53733f979bacd95c11290"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak3Y1WixKRqIX71qLt5P+rsxnOEK+y4Q+mVquA UI2iUJW9mGplpx09qTslVyxdVpjWf320img8LipTrUJFXw9nUOXD7vneWtC+YIFWPK6nDu6B4Tw1s7 h4NZzhA/3MFN+bI09JiXbuTw1UZH4eBgpHahrgYL3+BhHDACrv5UARYjYmXBQCY262y5pQ2vxM6JuV c=
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: Tue, 30 Apr 2019 18:41:58 -0000

MikeBishop commented on this pull request.

>  HTTP/3 endpoints contain a QPACK encoder and decoder. Each endpoint MUST
-initiate a single encoder stream and decoder stream. Receipt of a second
-instance of either stream type be MUST treated as a connection error of type
+initiate at most one encoder stream and one decoder stream. Receipt of a second

> Maybe swap the order to "one decoder stream and at most one encoder stream" to make it less likely to be misread as "at most one encoder stream and at most one decoder stream".

Perhaps this manifests a difference of opinion, but that's exactly how I read this text, and what I think it should say.  An implementation could defer creating both the decoder stream (because the peer hasn't yet sent anything that needs acknowledgement) and the encoder stream (because it doesn't intend to send anything on the dynamic table).

>  HTTP_WRONG_STREAM_COUNT. These streams MUST NOT be closed. Closure of either
 unidirectional stream type MUST be treated as a connection error of type
+An endpoint MAY avoid creating its own encoder stream if the maximum size of
+the dynamic table permitted by the peer is zero.
+An endpoint MAY avoid creating its own decoder stream if the maximum size of
+its own dynamic table is zero.
+An endpoint MUST allow its peer to create both encoder and decoder streams

> I think most implementations will take closed streams into account to know when to issue more uni stream credit. In the case of servers, there's never a need to increase it in vanilla HTTP/3. Clients need only increase it when they want more pushes (or grease, or extensions, etc).

Once the three basic streams are opened, servers never need to increase the number of streams, true.  However, the server still needs to keep giving credit as streams close until those three are opened at least.

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