Re: Clarification of dynamic table size change

Bence Béky <bnc@chromium.org> Wed, 14 September 2016 15:29 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 613AB12B38A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 14 Sep 2016 08:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.528
X-Spam-Level:
X-Spam-Status: No, score=-8.528 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.001, RP_MATCHES_RCVD=-1.508, 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=google.com header.b=VI7ZeMF/; dkim=pass (1024-bit key) header.d=chromium.org header.b=IEKcTtcF
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 fuYdo3VhqUsx for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 14 Sep 2016 08:28:57 -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 7D1A212BD3D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 14 Sep 2016 07:54:29 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bkBVA-0007xX-TO for ietf-http-wg-dist@listhub.w3.org; Wed, 14 Sep 2016 14:49:28 +0000
Resent-Date: Wed, 14 Sep 2016 14:49:28 +0000
Resent-Message-Id: <E1bkBVA-0007xX-TO@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 <bnc@google.com>) id 1bkBUy-0007wc-Gi for ietf-http-wg@listhub.w3.org; Wed, 14 Sep 2016 14:49:16 +0000
Received: from mail-oi0-f48.google.com ([209.85.218.48]) by maggie.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <bnc@google.com>) id 1bkBUw-0003Bg-Hs for ietf-http-wg@w3.org; Wed, 14 Sep 2016 14:49:16 +0000
Received: by mail-oi0-f48.google.com with SMTP id w11so24812967oia.2 for <ietf-http-wg@w3.org>; Wed, 14 Sep 2016 07:48:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=E46ARog3W+jAKAW+bRpyFJL2wzaBl14AH83PTSDelOE=; b=VI7ZeMF/xN1t80KzuqBD2KP8iwadgcRpV7CcULde30zZtMD0fSbprPNuC1gdVjqWts DmoLwnJw8EmyXGjqBQZqA9IvR4RoqYVM/9nUj2PwlTRWoW0MmAgmHmwZTPiLLlMcwz9/ IdOxe4vywD7GEf7nN6XZvXhrRrSaQSIgZD78Q3pv1kqjMLzvHTTAiqLuY0vlu5DbsO0O udWaiGtOMm1ecOgJir9a5pV/fMDr02Efi6QGZgK8wiPO+YenbQS8Vorjt+EgSkHXECu/ hdvMwNYZtMBSO/UjR8pcZ4GY+ek2wc86B2TzKrHxjtDh54MbOsGfgU8miGeg0yOdBy6o 5uCQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=E46ARog3W+jAKAW+bRpyFJL2wzaBl14AH83PTSDelOE=; b=IEKcTtcF9TnhsOfyLAn0jsf8EorYX/dWAi1xOLJGN0NevGDQvi7a3sMIwhd0i6mSMg OdL//54TzWac2/AlywPKWdjhzQf8JiONycEOtIGpDYUKyldUjmuLNz/3ds4Bnvq4v8gj f9XkLdxhaKUWKOcz5bnYNVgDvLzr5LmMGahe0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=E46ARog3W+jAKAW+bRpyFJL2wzaBl14AH83PTSDelOE=; b=XBLb9NwUg/t+QFEILR7MiUPT66f9klRdBg29eac34fLoE9Br5vOIRjFUMR0aDE3m1N ZugByFIPk1PQWguMYwQcSHoo86J3MwoavuYDDMcTcyUuLyfk3RCVKn2HQ+f0v8HRizXq xpn4PYRPS8nFjQEPTFe6Xk10uZ5nliDvMdvhZk1PpSjjj7rPMfqvLH9GP9fiAwEEpG6Y 9DzC3VMMBf7CZH0Igvdjk0UNtLA2RhOCE4J36iMwWPyvGVogPTrnbTXjUK/Z/yRW+sq5 XIm12xVD9uoGJ6wyroMgQM9GYXZRa3U0+WwWYXV5Jp59MtXRtfEiyeP5ZcAq+UPcoNAa Dcdw==
X-Gm-Message-State: AE9vXwO4WKtpRN/s9FnruW4qPGSuPftTMa0HldcpyHie8QgtctFqGuYk2oSk3B5fO/vV+dpPcAODqCPt+prx+dGt
X-Received: by 10.202.175.129 with SMTP id y123mr2631446oie.28.1473864527983; Wed, 14 Sep 2016 07:48:47 -0700 (PDT)
MIME-Version: 1.0
Sender: bnc@google.com
Received: by 10.157.1.137 with HTTP; Wed, 14 Sep 2016 07:48:27 -0700 (PDT)
In-Reply-To: <CAOdDvNrTdNzg+RGWQ_c8mVwT2MTb5rngxrFp0GYiMwT2oS3JNA@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> <CAPyZ6=Kh3EcB2dW7tk61CPuts+-Mwcd_TW8exn-Gg9vAuEzxBg@mail.gmail.com> <CAOdDvNrTdNzg+RGWQ_c8mVwT2MTb5rngxrFp0GYiMwT2oS3JNA@mail.gmail.com>
From: =?UTF-8?Q?Bence_B=C3=A9ky?= <bnc@chromium.org>
Date: Wed, 14 Sep 2016 10:48:27 -0400
X-Google-Sender-Auth: oIfkewoV8248mw0Qtdgre1UywHY
Message-ID: <CACMu3trvyCSD1WCHKFfv192SnXC9WcDQ08+m4VLGLaz0WUp1-Q@mail.gmail.com>
To: Patrick McManus <mcmanus@ducksong.com>
Cc: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, "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: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.218.48; envelope-from=bnc@google.com; helo=mail-oi0-f48.google.com
X-W3C-Hub-Spam-Status: No, score=-6.6
X-W3C-Hub-Spam-Report: AWL=0.810, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.216, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1bkBUw-0003Bg-Hs de46bac40bcce25b2a38f953064e2f5f
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Clarification of dynamic table size change
Archived-At: <http://www.w3.org/mid/CACMu3trvyCSD1WCHKFfv192SnXC9WcDQ08+m4VLGLaz0WUp1-Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32394
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 Tatsuhiro and Patrick,

Thank you very much for the clarification.  FYI Starting with release
54, Chrome will send out a SETTINGS_HEADER_TABLE_SIZE of 64 kB value
in the initial SETTINGS frame, allowing servers to experiment with
encoding using larger tables in hopes of more efficient compression.

Cheers,

Bence

On Thu, Aug 18, 2016 at 10:06 AM, Patrick McManus <mcmanus@ducksong.com> wrote:
> Tatsuhiro's description matches my understanding.
>
> -Patrick
>
>
> On Thu, Aug 18, 2016 at 9:50 AM, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
> wrote:
>>
>> 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
>>>>
>>>
>>
>