Re: [quicwg/base-drafts] create codec streams only when necessary (#2090)

Mike Bishop <notifications@github.com> Tue, 04 December 2018 18:24 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 674F2130ED9 for <quic-issues@ietfa.amsl.com>; Tue, 4 Dec 2018 10:24:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Level:
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 xIXov_jMcPZX for <quic-issues@ietfa.amsl.com>; Tue, 4 Dec 2018 10:24:36 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6F3130E9D for <quic-issues@ietf.org>; Tue, 4 Dec 2018 10:24:36 -0800 (PST)
Date: Tue, 04 Dec 2018 10:24:36 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1543947876; bh=jQ8tty8RRtMZe+o5kBhW5Mz5WebpVgdWgnzFgn0kVMo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ft0HNvlYA2YXNM7W2Q2/4winfDX8M3GINuOh9PbkneTHowbmaIjoAyIrm38TVO2qv kutBE+JaN4KowOZCpoSlK6eH8T8V+/ZvOO/hieeDHi9T+xgRZZSgEiHTyQoz94ELG4 yrI4qqBN3HYgacO9qKNjkarmG0H7R0CMyGK4rcss=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abef83b86ac61f16206fbf3b055642dc5994c3e83092cf00000001181e886392a169ce170ba08e@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2090/review/181408669@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2090@github.com>
References: <quicwg/base-drafts/pull/2090@github.com>
Subject: Re: [quicwg/base-drafts] create codec streams only when necessary (#2090)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c06c664385a_41c13f89d44d45c014270c4"; 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-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/1wzUpI_Po-zQhsXh-JQhTgIeIWw>
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: Tue, 04 Dec 2018 18:24:39 -0000

MikeBishop approved this pull request.

I'm of split mind on this.  I see the benefit for small implementations, though I suspect that benefit is marginal.  

At first glance, this seems like an implementation can no longer create the streams and then hand them to the encoder/decoder implementations -- the stream has to get lazily initialized, not sending the type byte until the codec is ready to send something further.  This probably also means not claiming a Stream ID either (use in order!), which means that the Stream ID allotment might not be there when you do go to send something.  Or, if you do claim the stream and then use a higher-numbered unidirectional stream, this one gets implicitly opened but the type byte is never sent, so it sits in limbo at the receiver.

However, I think the key here is in waiting until SETTINGS is received.  The new SETTINGS text says that you can operate in constrained mode (no dynamic table) before receiving SETTINGS.  That would mean that the call to the codec providing the streams and the table size is a step after the encoder and decoder are already operational, rather than start-up initialization.  This change, then, is simply a check in that call to determine whether to pass streams to the codec at all.

Seen from that perspective, this seems more palatable.

>  Receipt of a second instance of either stream type MUST be treated as a
 connection error of HTTP_WRONG_STREAM_COUNT.  Closure of either unidirectional
 stream MUST be treated as a connection error of type
 HTTP_CLOSED_CRITICAL_STREAM.
 
+An endpoint MUST NOT create an encoder stream if the maximum size of the
+dynamic table permitted by the peer is zero.  Observation of a peer-initiated
+encoder stream when the value is zero MUST be treated as a connection error of

"without sending a non-zero value for `SETTINGS_HEADER_TABLE_SIZE`"

>  Receipt of a second instance of either stream type MUST be treated as a
 connection error of HTTP_WRONG_STREAM_COUNT.  Closure of either unidirectional
 stream MUST be treated as a connection error of type
 HTTP_CLOSED_CRITICAL_STREAM.
 
+An endpoint MUST NOT create an encoder stream if the maximum size of the
+dynamic table permitted by the peer is zero.  Observation of a peer-initiated
+encoder stream when the value is zero MUST be treated as a connection error of
+type HTTP_QPACK_ENCODER_STREAM_ERROR.
+
+An endpoint MUST NOT create a decoder stream until the peer opens an encoder
+stream.  Observation of a peer-initiated decoder stream that lacks the
+corresponding encoder stream MUST be treated as a connection error of type

"when no encoder stream has been initiated locally"

-- 
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/2090#pullrequestreview-181408669