Return-Path: X-Original-To: quic-issues@ietfa.amsl.com Delivered-To: quic-issues@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1E2131275 for ; Wed, 12 Dec 2018 11:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 uQY_-QZ1JTaP for ; Wed, 12 Dec 2018 11:52:40 -0800 (PST) Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (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; d=github.com; 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: =?UTF-8?B?QmVuY2UgQsOpa3k=?= Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: 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 X-GitHub-Recipient-Address: quic-issues@ietf.org Archived-At: X-BeenThere: quic-issues@ietf.org 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 ----==_mimepart_5c11670477d8c_bd43f9df48d45c484783 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: https://github.com/quicwg/base-drafts/pull/2115#issuecomment-446721184 ----==_mimepart_5c11670477d8c_bd43f9df48d45c484783 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Martin, I think that's a great option. Please help me with the nom= enclature 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 entr= ies. 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 SETTING= S_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 f= eel strongly that they need consistent and distinct names (or phrases) fo= r 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 s= ize", sometimes within the same section, like 4.3.4.

What I drafted up was A: "table size", B: "Maximum Table Size", C: "li= mit on Maximum Table Size". Another option you are proposing, if I under= stand you correctly, is B: "table size", C: "maximum table size". Then w= e 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" e= very time. I'm fine with that.

A third option could be A: "table size" (which I think is the conventi= onal 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 t= ext is clean and unambiguous. Please tell me what your preference is. T= hanks.

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

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, o= r mute the thread.3D""

= ----==_mimepart_5c11670477d8c_bd43f9df48d45c484783--