Re: Clarification of dynamic table size change

Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> Thu, 18 August 2016 13:56 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BE212DEF2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 18 Aug 2016 06:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.267
X-Spam-Level:
X-Spam-Status: No, score=-8.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jAeeTpx2WbD7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 18 Aug 2016 06:56:00 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9330D12DEEB for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 18 Aug 2016 06:56:00 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1baNjY-000698-Tt for ietf-http-wg-dist@listhub.w3.org; Thu, 18 Aug 2016 13:51:48 +0000
Resent-Date: Thu, 18 Aug 2016 13:51:48 +0000
Resent-Message-Id: <E1baNjY-000698-Tt@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <tatsuhiro.t@gmail.com>) id 1baNjR-00066x-Lf for ietf-http-wg@listhub.w3.org; Thu, 18 Aug 2016 13:51:41 +0000
Received: from mail-pf0-f173.google.com ([209.85.192.173]) by maggie.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <tatsuhiro.t@gmail.com>) id 1baNjN-0008VK-Ft for ietf-http-wg@w3.org; Thu, 18 Aug 2016 13:51:40 +0000
Received: by mail-pf0-f173.google.com with SMTP id y134so6817230pfg.0 for <ietf-http-wg@w3.org>; Thu, 18 Aug 2016 06:51:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7OVP7lXY8LlH2aa2SwpSjUk0/BVT1ZC2bKiDvhghPbQ=; b=ZP2cb8xyHgJCIAFH1Jdo/5+tTg0zr7Uuyso+8bKEebyF4RnONpjSuWCD6AAyv9E0Dr A/YQdcngemxDcHP87HnAqksEp0S3mpTPkyQ+/AIqNUA/D2rdxfbxXYE/m4O7T8KnoLeT 3aMGPK56WqU+S7VYbCoses7bjMY/TEaQNq6GGZa0rYSETyejrneXdHKrIjgZmXVLxCRw fhailnq9pwq/qb5ynNyNUUi2x2KQYu0RVJ7L769SoUiFPMzr3SKymQgPcXrhERrC6Ta7 GSSv5qQpjD0L+oP3aXJNZNmIWaOwnbYzjxxkejBD0RHF9OQrwtWd9riy9UfzN/uGzRn/ nkrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7OVP7lXY8LlH2aa2SwpSjUk0/BVT1ZC2bKiDvhghPbQ=; b=CpifdmmEgtDlP2jXgNrdy5reCo+yu+StbdBxaRXXbpfwaxVIBciM00VNOHb/gecjEq 9Z9F+3DwY8QaoCu3DfzEXWA+htmglDlc2NrN5ZUTTm+pj+MDRBRZwEMG3affo/P0bpBv noA52zR5ZgCUXgMDjWHZdDJ5f2nW4VYhrnLrX7s3ttMsD31MxWXXWMelGTFEBA1jweyC 7wXDlBpT0OLTvvxavgklL5POC/D759VQQgz7KhHJ+U1ouU5Pe6EFHvLncH2QIy2AKn7I 5Yr4awZMO/9rUmo8pMtK/XwmzC72NrwMDYXRfoFktWx94GLumVn7j7zjpIEhzuXyURMy VAmQ==
X-Gm-Message-State: AEkoouuZ1yGbKil9j4QLjmF9nKSy9/F6m8q6IpnNGkyw49TZ8XKGT6kFlTPeAIk+gK3GLo5nZiKsjmCZx8IqXg==
X-Received: by 10.98.63.1 with SMTP id m1mr4311126pfa.14.1471528271286; Thu, 18 Aug 2016 06:51:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.165.103 with HTTP; Thu, 18 Aug 2016 06:50:50 -0700 (PDT)
In-Reply-To: <CACMu3tqeB7JhL-=OE=ixDNpe2gzbBndSAW+3+LODq7w52xuXrg@mail.gmail.com>
References: <CAPyZ6=+wnoJ4o3g4eS3B2Om3Yqk+wD1_9L6HKWqT8-A4cztnBQ@mail.gmail.com> <EC984486-0010-4B7D-953E-3D1F183C547D@lukasa.co.uk> <CAPyZ6=JVZnn-bwkXpRfPJxMVsTOxLsqhMFLsLZX3s9ojR6C8tA@mail.gmail.com> <3EE9A02C-794A-4147-A108-914AB19F2800@lukasa.co.uk> <56290C49.6040301@crf.canon.fr> <CAPyZ6=LzMHD6=_RUqEjViArGCPU=rPt6di-iZN54C5k0cb+CPg@mail.gmail.com> <20151023161519.GA26338@LK-Perkele-V2.elisa-laajakaista.fi> <CACMu3tqeB7JhL-=OE=ixDNpe2gzbBndSAW+3+LODq7w52xuXrg@mail.gmail.com>
From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Thu, 18 Aug 2016 22:50:50 +0900
Message-ID: <CAPyZ6=Kh3EcB2dW7tk61CPuts+-Mwcd_TW8exn-Gg9vAuEzxBg@mail.gmail.com>
To: =?UTF-8?Q?Bence_B=C3=A9ky?= <bnc@chromium.org>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, =?UTF-8?Q?Herv=C3=A9_Ruellan?= <herve.ruellan@crf.canon.fr>, Cory Benfield <cory@lukasa.co.uk>, Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary=94eb2c1130b8e31468053a58df16
Received-SPF: pass client-ip=209.85.192.173; envelope-from=tatsuhiro.t@gmail.com; helo=mail-pf0-f173.google.com
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.775, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1baNjN-0008VK-Ft 563ba566d2fa6f43b0fd03ceb3a2ee0c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Clarification of dynamic table size change
Archived-At: <http://www.w3.org/mid/CAPyZ6=Kh3EcB2dW7tk61CPuts+-Mwcd_TW8exn-Gg9vAuEzxBg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32314
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

​Hi,​

On Thu, Aug 18, 2016 at 10:31 PM, Bence Béky <bnc@chromium.org> wrote:

> Hi all,
>
> I'm sorry to revive this old thread, but there is one more case that I
> would
> like to request clarification for.  I was looking at both RFC 7540 and
> 7541, but
> could not find a definitive answer to the following question:  What is the
> initial maximum size of the dynamic table if there was a
> SETTINGS_HEADER_TABLE_SIZE value in the initial SETTINGS frame (the one
> part of
> the connection preface)?
>
> For example, suppose that the decoder sends a SETTINGS_HEADER_TABLE with
> value
> 64 * 1024 in the initial SETTINGS frame.  Do we think about the HPACK
> context to
> be created after the connection preface is sent, with a maximum dynamic
> table
> size of the current SETTINGS_HEADER_TABLE_SIZE value of 64 kB?  Or do we
> think
> about the HPACK context to be created before the connection preface is
> sent,
> with a default maximum dynamic table size of 4 kB?  Note that there is no
> synchronization issue even in the former case: if the decoder only evicts
> dynamic table entries above 64 kB from the very beginning, there is no
> harm in
> the encoder not starting to reference entries above 4 kB until it
> processes the
> decoder's initial SETTINGS frame.
>
> Suppose that the encoder does not emit a "dynamic table size update" HPACK
> instruction after this.  The consensus on this e-mail thread seems to be
> that
> this is acceptable as long as the encoder means "no change" to the maximum
> dynamic table size.  It is, however, important that the encoder and the
> decoder
> are in agreement about the initial maximum dynamic table size, relative to
> which
> the encoder means "no change".  For example, if the decoder is under the
> impression that the maximum dynamic table size is 4 kB, while the encoder
> takes
> it to be 64 kB, then the decoder will signal a CONNECTION_ERROR as soon as
> the
> encoder references an entry above 4 kB.  If, on the other hand, the encoder
> thinks it's 4 kB and never references entries above that, then the decoder
> would
> waste memory if it kept 64 kB worth of entries.
>
> Given that a decoder can send a SETTINGS_HEADER_TABLE_SIZE with a value
> lower
> than the default, and the encoder can start compressing headers before
> receiving
> the initial SETTINGS frame, it seems necessary to me to understand the
> initial
> maximum dynamic table size to be 4 kB, and to require the decoder to store
> this
> much entries until it receives the dynamic table size update HPACK
> instruction
> from the encoder.  Otherwise a COMPRESSION_ERROR arises due to the
> synchronization issue even if the peers agree that the initial size is the
> new
> (lower) value.  Unless, of course,  we want to formulate different
> requirements
> depending on whether the SETTINGS_HEADER_TABLE_SIZE value is greater than
> or
> less than the default.
>
> If I implement a decoder in this spirit, that is, one that sends a
> SETTINGS_HEADER_TABLE_SIZE of 64 kB in the initial SETTINGS frame, but
> does not
> allow more than default memory for the dynamic table until it receives a
> dynamic
> table size update from the encoder, would it be incompatible with anybody's
> current implementation?
>
>
According to this thread, ​I'm under impression ​that this is OK, and until
you get dynamic table size update, default 4KiB dynamic table limit still
applies.

As for initial value of dynamic table size, I think it is 4KiB regardless
of SETTINGS.  We create HTTP/2 session before doing any parameter
modification, including header table size change.  At this moment, table
size if 4KiB, RFC default.  After that, decoder send
SETTINGS_HEADER_TABLE_SIZE with whatever value they want.  Then after
SETTINGS ACK, and HPACK table size update, dynamic table size is finally
synchronized, and changed to the value encoder sent in HPACK table size
update (as long as it is equal or smaller than decoder sent in SETTINGS).

Best regards,
Tatsuhiro Tsujikawa




> Best regards,
>
> Bence Béky
>
>
> On Fri, Oct 23, 2015 at 12:15 PM, Ilari Liusvaara <
> ilariliusvaara@welho.com> wrote:
>
>> On Sat, Oct 24, 2015 at 12:45:49AM +0900, Tatsuhiro Tsujikawa wrote:
>> > Hi,
>> >
>> > On Fri, Oct 23, 2015 at 1:18 AM, Hervé Ruellan <
>> herve.ruellan@crf.canon.fr>
>> > wrote:
>> >
>> > > I agree that the wording is ambiguous here.
>> > >
>> > > However, my reading is the same a Cory's: you don't have to send a
>> dynamic
>> > > table update if the *actual* value is not changed.
>> > >
>> > >
>> > ​I also found the discussion in this ML indicating you are right.  Thank
>> > you for clarification.
>> > I have to ask one more question: what is *actual* value? Is it the table
>> > size both peer agreed before reading SETTINGS, or the value in
>> > SETTINGS_HEADER_TABLE_SIZE decoder sent?
>> >
>> > I think this is a good item to add in FAQ section..
>>
>> The way negotiation works:
>> - Decoder side sets the upper bound via SETTINGS_HEADER_TABLE_SIZE.
>> - Encoder side sets the actual size via dynamic table updates (inside
>>   HPACK bitstream) within limits set by decoder.
>> - If between headers decoder reduces the limit below size signaled by
>>   encoder, the encoder must first reduce the table size to the minimum
>>   it was between the frames or less (it can then increase it up to
>>   current limit).
>>
>> As example of the last point:
>> [4k dynamic table size in use]
>> --> HEADERS
>> <-- SETTINGS(SETTINGS_HEADER_TABLE_SIZE=4k)
>> <-- SETTINGS(SETTINGS_HEADER_TABLE_SIZE=2k)
>> <-- SETTINGS(SETTINGS_HEADER_TABLE_SIZE=4k)
>> <-- SETTINGS(SETTINGS_HEADER_TABLE_SIZE=8k)
>> <-- SETTINGS(SETTINGS_HEADER_TABLE_SIZE=6k)
>> --> HEADERS
>>
>> The second HEADERS must first reduce the dynamic table to at most
>> 2k. It can then increase dynamic table size to up to 6k.
>>
>>
>> -Ilari
>>
>>
>