[quicwg/base-drafts] Initial maximum table size needs clarification. (#2258)
Bence Béky <notifications@github.com> Wed, 26 December 2018 15:35 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 46E1B1274D0 for <quic-issues@ietfa.amsl.com>; Wed, 26 Dec 2018 07:35:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.085
X-Spam-Level:
X-Spam-Status: No, score=-7.085 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, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 vlz5AOiT8bya for <quic-issues@ietfa.amsl.com>; Wed, 26 Dec 2018 07:35:01 -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 1B4FF1271FF for <quic-issues@ietf.org>; Wed, 26 Dec 2018 07:35:01 -0800 (PST)
Date: Wed, 26 Dec 2018 07:34:59 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1545838499; bh=fBDUMBpeSKNlXGESDMlgGvU3A14Ot/lDF5A37aQ1weM=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=AhaLenJAX5EFCBIliHuc0v1k35DSc/BJ5kqwsTebsI3M5i79DsKh2Zq+kiiWUa5a8 Wv5693B0PxxacMQpzGNTP5hTKszOdX4ybzAbjlUoW18pNw9UTjEqegU9VRmlJeT53u Da4X9b9H5jYFvsoYZOYj0eBFKNjjhvkDdZuWhz1c=
From: Bence Béky <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab0f76894c62a7bb7a400d03b1af163e437ebb57a892cf00000001183b61a392a169ce177edca7@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2258@github.com>
Subject: [quicwg/base-drafts] Initial maximum table size needs clarification. (#2258)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c239fa3c842d_66813fd8910d45b8440518"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: bencebeky
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/n5EUTKdovuxh5ekNbO1ToM0wJg8>
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, 26 Dec 2018 15:35:03 -0000
Initial maximum table size needs clarification. A QPACK context is shared between the encoder of one endpoint, call it endpoint A, and the decoder of another endpoint, call it endpoint B. Endpoint A is the one sending HTTP messages (requests or responses). (There is another, completely independent QPACK context shared between the encoder of B and the decoder of A used for messages sent by B.) A and B must have a shared understanding of the initial maximum table size for this context. In HTTP/3, endpoint B can send endpoint A a SETTINGS_HEADER_TABLE_SIZE setting. In https://quicwg.org/base-drafts/draft-ietf-quic-qpack.html#maximum-table-size, it is difficult for me to apply the sentence "The initial maximum size is determined by the corresponding setting when HTTP requests or responses are first permitted to be sent." from B's prospective, because B does not sent HTTP messages using this QPACK context. And from A's prospective, I understand that A is allowed to send messages before receiving B's SETTINGS frame, at which point the value of SETTINGS_HEADER_TABLE_SIZE is zero according to issue #2038 in the 1-RTT case, in contradiction with the current last sentence of this paragraph. Similarily, I find the phare "the initial maximum table size is the value of the setting in the peer’s SETTINGS frame" confusing from B's prospective, because it is B, not its peer sending the relevant SETTING. I propose to reword this paragraph. In the 1-RTT case, there are two options for the initial maximum table size: zero, see #2256, or the value of SETTINGS_HEADER_TABLE_SIZE, see #2257. In either case, the encoder cannot insert entries into the dynamic table until it receives the SETTINGS frame from the decoder. As for the case where QPACK is used in a protocol other than HTTP/3, I feel like the initial maximum table size can either be left unspecified, placing the burden on that other protocol. Another option is to define it to be zero unless that other protocol specifies otherwise. -- 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/issues/2258
- [quicwg/base-drafts] Initial maximum table size n… Bence Béky
- Re: [quicwg/base-drafts] Initial maximum table si… Martin Thomson
- Re: [quicwg/base-drafts] Initial maximum table si… Kazuho Oku
- Re: [quicwg/base-drafts] Initial maximum table si… Martin Thomson
- Re: [quicwg/base-drafts] Initial maximum table si… Bence Béky
- Re: [quicwg/base-drafts] Initial maximum table si… afrind
- Re: [quicwg/base-drafts] Initial maximum table si… afrind