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

Lucas Pardue <notifications@github.com> Thu, 21 March 2019 19:23 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3472128709 for <quic-issues@ietfa.amsl.com>; Thu, 21 Mar 2019 12:23:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 aB8KNfwukkBm for <quic-issues@ietfa.amsl.com>; Thu, 21 Mar 2019 12:23:43 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E782B126C87 for <quic-issues@ietf.org>; Thu, 21 Mar 2019 12:23:42 -0700 (PDT)
Date: Thu, 21 Mar 2019 12:23:41 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1553196221; bh=KrakFkuUiqAiBATJSO4aoW9UcmGJjyjOBO77iD0kYfw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Yic70jfr63bXB/mqPxmCp/Kn5ubqxFpjmKbLArNvW6q/T6MkYAH7h6l9Gc1pjHDfL Px/U1SOA7niFJhnBJnCK3nrbtcEIvzBefdZL+Ud1lrF5ycJqOFO497hbpv8I8dYDH4 0SIdh3iuXRZ4Njn8N9C6VZfSOBSsJvUutCcKq2lg=
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4aba08a8f36fe653988712adee676b56246766df76892cf0000000118aba6bd92a169ce1931c3e6@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2529/review/217445805@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2529@github.com>
References: <quicwg/base-drafts/pull/2529@github.com>
Subject: Re: [quicwg/base-drafts] Allow not creating QPACK codec streams (#2529)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c93e4bd73752_40f73f9ad46d45bc1449f3"; 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-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/P5upcgbiLDKbAkFhTBrsJV-afAw>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2019 19:23:45 -0000

LPardue commented on this pull request.



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

Thinking about this a little more, its a nice feature of HPACK that it can chose when to start using dynamic compression, with little overhead. 

My understanding though is that we can't use MAX_STREAMS to contorl concurrency like you describe (I'm probably wrong here). But from the transport document section 19.11

> Note that these frames (and the corresponding transport parameters)
   do not describe the number of streams that can be opened
   concurrently.  The limit includes streams that have been closed as
   well as those that are open.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2529#discussion_r267920794