Re: [quicwg/base-drafts] Clean up text on Maximum Table Size. (#2115)

Bence Béky <> Wed, 12 December 2018 19:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA1E2131275 for <>; Wed, 12 Dec 2018 11:52:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.481
X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, GB_SUMOF=5, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uQY_-QZ1JTaP for <>; Wed, 12 Dec 2018 11:52:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3B73131270 for <>; Wed, 12 Dec 2018 11:52:37 -0800 (PST)
Date: Wed, 12 Dec 2018 11:52:36 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1544644356; bh=WO/8NCbC0PplQV0icUyMwJl65U9mY9jQ/vVlIA/tZ2E=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=MbronnTWOCzqIYNUnuk0s2OAHHi63yHNhZkO+Moj5ZW9wOIdROt/ZEtJI1imGyV1q anLymKz/o+lcKPpoHflpJov+kduij8yGfTAN8SNQOWZ2T8Wehk0U/ExMQSvygR9KT1 ozCgrukz8iSmkuiPXSwf6yioPTqYmX9Igs0bb4gg=
From: Bence Béky <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2115/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Clean up text on Maximum Table Size. (#2115)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c11670477d8c_bd43f9df48d45c484783"; 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
Archived-At: <>
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, 12 Dec 2018 19:52:43 -0000

Hi Martin, I think that's a great option.  Please help me with the nomenclature here.  There are three distinct quantities at play:

A: The sum of the size of the entries in the dynamic table.

B: The amount of memory the decoder is required for dynamic table entries.  Oldest entries that do not fit in B will be evicted.  This quantity can be changed unilaterally by the encoder as long as it does not exceed C.

C: Hard limit on B.  In HTTP/3, this is set by the decoder via SETTINGS_HEADER_TABLE_SIZE.

All three quantities have to be discussed in the spec, and a compliant optimal decoder needs to keep track of all three of them.  Therefore I feel strongly that they need consistent and distinct names (or phrases) for them.

Currently the spec consistently uses "(dynamic) table size" for A (for example, first sentence of 3.2.2) and "maximum (dynamic) table size" or "maximum size of the dynamic table" for C (for example, when calculating MaxEntries or in 4.4.3 when talking about omitting stream cancellations).  For B, the spec sometimes uses "table size", sometimes "maximum table size", sometimes within the same section, like 4.3.4.

What I drafted up was A: "table size", B: "Maximum Table Size", C: "limit on Maximum Table Size".  Another option you are proposing, if I understand you correctly, is B: "table size", C: "maximum table size".  Then we need to find something for A, like "table load" or "table utilization" or "table memory footprint", or just write out "sum of size of entries" every time.  I'm fine with that.

A third option could be A: "table size" (which I think is the conventional meaning of "size"); C: "maximum table size", and find something for B, like "table capacity".

I do not have a strong opinion on any of these names, as long as the text is clean and unambiguous.  Please tell me what your preference is.  Thanks.

As for the reordering of large chunks of text, sorry for mixing that in with this PR.  I'll draft a separate PR for that and rebase this one on that.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: