[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) (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

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: