Re: Clarification of dynamic table size change

Bence Béky <> Thu, 18 August 2016 13:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 428E012DE83 for <>; Thu, 18 Aug 2016 06:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.267
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: (amavisd-new); dkim=pass (2048-bit key) header.b=DUgWhtzY; dkim=pass (1024-bit key) header.b=cFUJ9k7i
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ps5RJdIfT_-2 for <>; Thu, 18 Aug 2016 06:36:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9FEA12DE75 for <>; Thu, 18 Aug 2016 06:36:30 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1baNQd-0006o7-Qi for; Thu, 18 Aug 2016 13:32:15 +0000
Resent-Date: Thu, 18 Aug 2016 13:32:15 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1baNQW-0006ig-2H for; Thu, 18 Aug 2016 13:32:08 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1baNQP-0002dy-GK for; Thu, 18 Aug 2016 13:32:06 +0000
Received: by with SMTP id f189so22019722oig.3 for <>; Thu, 18 Aug 2016 06:31:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uZSf0is45ERe3EFPmpXLtDNaq4+Cqst0ODC58qpycis=; b=DUgWhtzY+wkENPQBaFtG6dLzC37V4onXnq1q3OViFywgcWpaNHLDhRZryv1FiZJE3P B425cmC7HgNStHHpI6dinLQitmrpt7pBia50MkFi5HWIv8YBIEAUALvDFCjKDZQZsAFE 0yp/l90H538B2V99mQKLfaLlgvzRT0A1VYOuMznmGJ8OFm6b3EARE1v7zyc97JwX5iDk UJsspS74BxYKj23ChjGCts6ReAnWU5yN+Z0YKzwnTY2cJEYm64ezQpqyxyB/lZunMCiR VWvbmvP9JUAqUqTpXlOvjtckpUklSm0kgrV1YEMCLKfx3wFWjE+eWNAIUtXKtV7FoOq/ dX/g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uZSf0is45ERe3EFPmpXLtDNaq4+Cqst0ODC58qpycis=; b=cFUJ9k7i7lqdwnWTFlIV1WvyUqrOlvA9Ur9+jfsp6W+UOXghdbXNtDG4sBTRijBNsH A/lvinod0rH4OhxVohNDVNefiCnAoyWuUZrbG5HA4o8enIeeNJG4yLP9hdlgVyyjWMb7 wN/F0/jzBPlLmh61eyZ9UWDKVYfzfffVex6R8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uZSf0is45ERe3EFPmpXLtDNaq4+Cqst0ODC58qpycis=; b=hZTbRyeQDx919uFlRk1Wcv9DqZ1acCjJu2iXYsDwCLas/dbCgu6jyXK6guCXYOAEd/ 3YyTD+KdaU3MK88oagV4W3Z9xb3pnYcDKM1YWe42WY0GImvVMCfymRVlXv6dbz8ZPNq1 M7YmsQ1GBfUn1JZ4zxAxBkmhB7q7VNZsrUwUEDRXbKAGXaixNYwWrneyMXbWhMVHLgiV pMVj+gLFI/85n3ppSi38NDlfakNG2ysceMHY1IQJyQOlcH6qEXXx0jn0FqcAOeyK/Z4e ymmyu5PiYSDSlVx8VBCiZUAWsd3mEf5Myj8wCYaxz0cc/fBzac37alKD6N0xcjcF4UY+ doaA==
X-Gm-Message-State: AEkoousRyHCYPZ+xILQykQXrarOTLJ6jhlKJzMUd8K+6F0lLp8KR2mkQN+0P8zggorzVp7DnKfyAPMszA427zA2K
X-Received: by with SMTP id t197mr1248475oih.27.1471527095436; Thu, 18 Aug 2016 06:31:35 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 18 Aug 2016 06:31:15 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: =?UTF-8?Q?Bence_B=C3=A9ky?= <>
Date: Thu, 18 Aug 2016 09:31:15 -0400
X-Google-Sender-Auth: yUXiunC_lU3rj5pozIsxYyrfWs0
Message-ID: <>
To: "" <>
Cc: Tatsuhiro Tsujikawa <>, =?UTF-8?Q?Herv=C3=A9_Ruellan?= <>, Cory Benfield <>, Ilari Liusvaara <>
Content-Type: multipart/alternative; boundary=001a113decbccd60e6053a589966
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.0
X-W3C-Hub-Spam-Report: AWL=0.226, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1baNQP-0002dy-GK 2e71e44fe2ffe058b9b1af445da4b292
Subject: Re: Clarification of dynamic table size change
Archived-At: <>
X-Mailing-List: <> archive/latest/32312
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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
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
size of the current SETTINGS_HEADER_TABLE_SIZE value of 64 kB?  Or do we
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
the encoder not starting to reference entries above 4 kB until it processes
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
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
are in agreement about the initial maximum dynamic table size, relative to
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
it to be 64 kB, then the decoder will signal a CONNECTION_ERROR as soon as
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
waste memory if it kept 64 kB worth of entries.

Given that a decoder can send a SETTINGS_HEADER_TABLE_SIZE with a value
than the default, and the encoder can start compressing headers before
the initial SETTINGS frame, it seems necessary to me to understand the
maximum dynamic table size to be 4 kB, and to require the decoder to store
much entries until it receives the dynamic table size update HPACK
from the encoder.  Otherwise a COMPRESSION_ERROR arises due to the
synchronization issue even if the peers agree that the initial size is the
(lower) value.  Unless, of course,  we want to formulate different
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
allow more than default memory for the dynamic table until it receives a
table size update from the encoder, would it be incompatible with anybody's
current implementation?

Best regards,

Bence Béky

On Fri, Oct 23, 2015 at 12:15 PM, Ilari Liusvaara <>

> 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 <
> > 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
> >
> > 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]
> 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