Return-Path: 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 ; 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 ; 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 ; 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: =?UTF-8?B?QmVuY2UgQsOpa3k=?= Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: 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: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.29 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2018 15:35:03 -0000 ----==_mimepart_5c239fa3c842d_66813fd8910d45b8440518 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Initial maximum table size needs clarification.=0D =0D A QPACK context is shared between the encoder of one endpoint, call it en= dpoint=0D A, and the decoder of another endpoint, call it endpoint B. Endpoint A i= s the=0D one sending HTTP messages (requests or responses). (There is another,=0D= completely independent QPACK context shared between the encoder of B and = the=0D decoder of A used for messages sent by B.) A and B must have a shared=0D= understanding of the initial maximum table size for this context. In HTT= P/3,=0D endpoint B can send endpoint A a SETTINGS_HEADER_TABLE_SIZE setting.=0D =0D In https://quicwg.org/base-drafts/draft-ietf-quic-qpack.html#maximum-tabl= e-size,=0D it is difficult for me to apply the sentence "The initial maximum size is= =0D determined by the corresponding setting when HTTP requests or responses a= re=0D first permitted to be sent." from B's prospective, because B does not sen= t HTTP=0D messages using this QPACK context. And from A's prospective, I understan= d that=0D A is allowed to send messages before receiving B's SETTINGS frame, at whi= ch=0D point the value of SETTINGS_HEADER_TABLE_SIZE is zero according to issue = #2038=0D in the 1-RTT case, in contradiction with the current last sentence of thi= s=0D paragraph.=0D =0D Similarily, I find the phare "the initial maximum table size is the value= of the=0D setting in the peer=E2=80=99s SETTINGS frame" confusing from B's prospect= ive, because=0D it is B, not its peer sending the relevant SETTING.=0D =0D I propose to reword this paragraph. In the 1-RTT case, there are two opt= ions=0D for the initial maximum table size: zero, see #2256, or the value of=0D SETTINGS_HEADER_TABLE_SIZE, see #2257. In either case, the encoder=0D cannot insert entries into the dynamic table until it receives the SETTIN= GS frame=0D from the decoder.=0D =0D As for the case where QPACK is used in a protocol other than HTTP/3, I fe= el like=0D the initial maximum table size can either be left unspecified, placing th= e=0D burden on that other protocol. Another option is to define it to be zero= unless=0D that other protocol specifies otherwise.=0D =0D -- =0D You are receiving this because you are subscribed to this thread.=0D Reply to this email directly or view it on GitHub:=0D https://github.com/quicwg/base-drafts/issues/2258= ----==_mimepart_5c239fa3c842d_66813fd8910d45b8440518 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Initial maximum table size needs clarification.

=0D

A QPACK context is shared between the encoder of one endpoint, call it= endpoint
=0D A, and the decoder of another endpoint, call it endpoint B. Endpoint A i= s the
=0D one sending HTTP messages (requests or responses). (There is another,=0D completely independent QPACK context shared between the encoder of B and = the
=0D decoder of A used for messages sent by B.) A and B must have a shared=0D understanding of the initial maximum table size for this context. In HTT= P/3,
=0D endpoint B can send endpoint A a SETTINGS_HEADER_TABLE_SIZE setting.

=0D=

In https://quicwg.org/base-drafts/dra= ft-ietf-quic-qpack.html#maximum-table-size,
=0D it is difficult for me to apply the sentence "The initial maximum size is=
=0D determined by the corresponding setting when HTTP requests or responses a= re
=0D first permitted to be sent." from B's prospective, because B does not sen= t HTTP
=0D messages using this QPACK context. And from A's prospective, I understan= d that
=0D A is allowed to send messages before receiving B's SETTINGS frame, at whi= ch
=0D point the value of SETTINGS_HEADER_TABLE_SIZE is zero according to issue = #2038
=0D in the 1-RTT case, in contradiction with the current last sentence of thi= s
=0D paragraph.

=0D

Similarily, I find the phare "the initial maximum table size is the va= lue of the
=0D setting in the peer=E2=80=99s SETTINGS frame" confusing from B's prospect= ive, because
=0D it is B, not its peer sending the relevant SETTING.

=0D

I propose to reword this paragraph. In the 1-RTT case, there are two = options
=0D for the initial maximum table size: zero, see #2256, or the= value of
=0D SETTINGS_HEADER_TABLE_SIZE, see #2257. In either case, the= encoder
=0D cannot insert entries into the dynamic table until it receives the SETTIN= GS frame
=0D from the decoder.

=0D

As for the case where QPACK is used in a protocol other than HTTP/3, I= feel like
=0D the initial maximum table size can either be left unspecified, placing th= e
=0D burden on that other protocol. Another option is to define it to be zero= unless
=0D that other protocol specifies otherwise.

=0D =0D

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.3D""

=0D =0D = ----==_mimepart_5c239fa3c842d_66813fd8910d45b8440518--