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

Kazuho Oku <notifications@github.com> Wed, 19 December 2018 21:16 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 5D8F4130EC9 for <quic-issues@ietfa.amsl.com>; Wed, 19 Dec 2018 13:16:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.065
X-Spam-Level:
X-Spam-Status: No, score=-8.065 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, 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 GDuda2wHtSTy for <quic-issues@ietfa.amsl.com>; Wed, 19 Dec 2018 13:16:03 -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 A6640130E86 for <quic-issues@ietf.org>; Wed, 19 Dec 2018 13:16:03 -0800 (PST)
Date: Wed, 19 Dec 2018 13:16:02 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1545254162; bh=3iVx8X20SPUIOesb3ts97qVbh5SVac/Ym/TpwP5KCO4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=LgXc9QWHiLCQfdbPdWm8MSudAPUSxJze45MCSF80I8/Uy/gbNl5KEef+6VLdJ4fMX uvCQP8rZHv1IGO5o+WS5K9vYYL5wDDfXjdeHybkmFeugNVJIRqj+3ENz3mjz6vQvdp ICRgfTI7/V4CxlO6UlwuOlT4Fkv3LGup+k9CeB8Q=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab6d3d496f2e4bb219202cafc513fc1bfb1cceec6b92cf000000011832771292a169ce170ba08e@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/c448746507@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_5c1ab512cbb69_62e83ff96d4d45bc118293"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/hx2HwvtiLfLN_ok0LECQg3b2sbs>
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: Wed, 19 Dec 2018 21:16:05 -0000

@afrind 
> What if we let the memory constrained implementation prevent the creation of the encoder/decoder streams by limiting the number of peer initiated unidirectional streams, rather than requiring lazy creation?

In addition to the reset issue, IIUC we do not currently require the endpoints to open QPACK codec streams before the control streams. We'd need to fix that, otherwise, there's a risk that endpoints that restrict the number of unidirectional streams would suffer multiple round-trips to exchange SETTINGS. However, requiring the streams to be in particular order (i.e. particular streams to have particular stream IDs) contradicts to our current approach of using the type byte rather than the stream IDs for identifying unidirectional streams.

-- 
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#issuecomment-448746507