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

Bence Béky <> Tue, 18 December 2018 16:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8F46130EE7 for <>; Tue, 18 Dec 2018 08:16:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.06
X-Spam-Status: No, score=-6.06 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.105, 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 2W4_p_0qdfOJ for <>; Tue, 18 Dec 2018 08:16:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2051A130EE3 for <>; Tue, 18 Dec 2018 08:16:29 -0800 (PST)
Date: Tue, 18 Dec 2018 08:16:27 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1545149787; bh=LliW2VDnIQfiZSGY36Cjfv3joeCgh4mg4tyLSHcsBOE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=zRwtBIkFUnHgklnjwFswULy9GsyK4oygZNwdJSk1MvCO9Kt0u7e2bTGQL0PqVIqqA KReDxqAcjNzYCAKuqKwpNrEEUXdAsGTivelbcZJ3bVWUDHjglXFFAnRddgHcdjZ9J1 z46UEeD+eq5aHjOPWZmappdSwF0dj2n3A8DismOs=
From: Bence Béky <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2115/review/>
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_5c191d5bdbd1_42993f8e486d45b4278088"; 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: Tue, 18 Dec 2018 16:16:33 -0000

bencebeky commented on this pull request.

> -requests or responses are first permitted to be sent. For clients using 0-RTT
-data in HTTP/3, the table size is the remembered value of the setting, even if
-the server later specifies a larger maximum in its SETTINGS frame.  For HTTP/3
-servers and HTTP/3 clients when 0-RTT is not attempted or is rejected, the
-initial maximum table size is the value of the setting in the peer's SETTINGS
+The initial dynamic table capacity is the value of the maximum dynamic table
+capacity when HTTP requests or responses are first permitted to be sent.  For
+HTTP/3 servers and HTTP/3 clients when 0-RTT is not attempted or is rejected,
+the initial maximum table capacity is zero.  For clients using 0-RTT data in
+HTTP/3, the initial table capacity is the remembered value of the setting, even
+if the server later specifies a different maximum dynamic table capacity in its
+SETTINGS frame.  It is not an error for the SETTINGS frame to contain a
+SETTINGS_MAXIMUM_DYNAMIC_TABLE_CAPACITY value lower than the initial table
+capacity on a 0-RTT connection; the maximum dynamic table capacity only limits
+subsequent table capacity changes.  However, if an endpoint receives a

This is so that a decoder can request reduction of maximum dynamic table capacity on a new connection.

There are other, much simpler options:
1. Ban an endpoint from sending a SETTINGS_MAXIMUM_DYNAMIC_TABLE_CAPACITY value on a 0-RTT connection that is smaller than the remembered value.
2. Have the maximum table capacity always default to 0, even on a 0-RTT connection, until the SETTINGS frame is received.

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