Re: Clarification of dynamic table size change

Bence Béky <bnc@chromium.org> Thu, 18 August 2016 13:36 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 428E012DE83 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 18 Aug 2016 06:36:33 -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=google.com header.b=DUgWhtzY; dkim=pass (1024-bit key) header.d=chromium.org header.b=cFUJ9k7i
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 ps5RJdIfT_-2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 18 Aug 2016 06:36:31 -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 D9FEA12DE75 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 18 Aug 2016 06:36:30 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1baNQd-0006o7-Qi for ietf-http-wg-dist@listhub.w3.org; Thu, 18 Aug 2016 13:32:15 +0000
Resent-Date: Thu, 18 Aug 2016 13:32:15 +0000
Resent-Message-Id: <E1baNQd-0006o7-Qi@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <bnc@google.com>) id 1baNQW-0006ig-2H for ietf-http-wg@listhub.w3.org; Thu, 18 Aug 2016 13:32:08 +0000
Received: from mail-oi0-f52.google.com ([209.85.218.52]) by lisa.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <bnc@google.com>) id 1baNQP-0002dy-GK for ietf-http-wg@w3.org; Thu, 18 Aug 2016 13:32:06 +0000
Received: by mail-oi0-f52.google.com with SMTP id f189so22019722oig.3 for <ietf-http-wg@w3.org>; Thu, 18 Aug 2016 06:31:41 -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; 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; d=chromium.org; 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; d=1e100.net; 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 10.202.245.206 with SMTP id t197mr1248475oih.27.1471527095436; Thu, 18 Aug 2016 06:31:35 -0700 (PDT)
MIME-Version: 1.0
Sender: bnc@google.com
Received: by 10.157.43.143 with HTTP; Thu, 18 Aug 2016 06:31:15 -0700 (PDT)
In-Reply-To: <20151023161519.GA26338@LK-Perkele-V2.elisa-laajakaista.fi>
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>
From: =?UTF-8?Q?Bence_B=C3=A9ky?= <bnc@chromium.org>
Date: Thu, 18 Aug 2016 09:31:15 -0400
X-Google-Sender-Auth: yUXiunC_lU3rj5pozIsxYyrfWs0
Message-ID: <CACMu3tqeB7JhL-=OE=ixDNpe2gzbBndSAW+3+LODq7w52xuXrg@mail.gmail.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Cc: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, =?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=001a113decbccd60e6053a589966
Received-SPF: pass client-ip=209.85.218.52; envelope-from=bnc@google.com; helo=mail-oi0-f52.google.com
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: lisa.w3.org 1baNQP-0002dy-GK 2e71e44fe2ffe058b9b1af445da4b292
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Clarification of dynamic table size change
Archived-At: <http://www.w3.org/mid/CACMu3tqeB7JhL-=OE=ixDNpe2gzbBndSAW+3+LODq7w52xuXrg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32312
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 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?

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