IETF Logo Mail Archive

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

afrind <notifications@github.com> Tue, 18 December 2018 21:54 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 1D57E130934 for <quic-issues@ietfa.amsl.com>; Tue, 18 Dec 2018 13:54:15 -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 vnSePi_I11Tt for <quic-issues@ietfa.amsl.com>; Tue, 18 Dec 2018 13:54:12 -0800 (PST)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76714129BBF for <quic-issues@ietf.org>; Tue, 18 Dec 2018 13:54:12 -0800 (PST)
Date: Tue, 18 Dec 2018 13:54:11 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1545170051; bh=PREPRPhnTYafzoMTvgHd8D9DrUZnvEoMu5S97gu4IkQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=xa/Pv1bAH72Fu+nr3m1prnTBwMLoc0MKAOo3hBpWEf5mEUekgkaAFF6L7NI//h1Dh a2q7lExvZN27DTa/7Ad2h297aqKfhzOiKvkiI1dH3HFh2Kw8jovfgSHP7LUFblYF5i Fpvsj28zali3x19ZL73K42vrKFHxKda9HBmDEBqY=
From: afrind <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab7ae785351b4739040e6335e383e0e05198f52a1d92cf0000000118312e8392a169ce170ba08e@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/c448384835@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_5c196c8315b9c_29de3f9678cd45bc295ab"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: afrind
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/ZXA0omRnQzaNXUmrkyikOBU3eBM>
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, 18 Dec 2018 21:54:15 -0000

@dtikhonov : yes, I guess I'm assuming that memory constrained implementations that don't really implement qpack aren't going to support push either.  And they are not going to support any extensions that require more than one unidirectional stream.  Per @kazuho's original problem statement:

> Avoiding creation them is beneficial for memory-constrained devices, because they can configure the QUIC transport stack to handle at most one unidirectional stream

Is anyone actually building a memory constrained implementation that would like to weigh in here?  It strikes me as pretty simple to just receive a qpack unidirectional stream and discard it, or as @lnicco suggests, reset it.  

My thoughts around implementing a simpler version of qpack was that you wouldn't be required to open your own encoder/decoder stream.


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

v2.23.0 | Report a Bug | By Email