Re: [quicwg/base-drafts] Send complete SETTINGS (#2972)

Mike Bishop <> Mon, 19 August 2019 20:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20E16120936 for <>; Mon, 19 Aug 2019 13:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 eTME7JsCjGW0 for <>; Mon, 19 Aug 2019 13:03:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 009DD12095E for <>; Mon, 19 Aug 2019 13:03:11 -0700 (PDT)
Date: Mon, 19 Aug 2019 13:03:10 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1566244991; bh=oVE7mkkfbfaDNd8wpmxtjUP2S//BBaiI8/pdXOjTS0A=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=1f8j/sATMcqQaj67vhG0/wi/GMZ3M7wjvOWR7b9XJF6ZaONuWWou+1vVaR4HA/A9F AFh7+aTaq7TQ6FHLza3djh7bS3Z5nfaU7H4Si3lWqa4+0BfGyWi4wl6T+lTYToHV2X bILqlHgOGZnSmivyZHY7+labUIpcfe/7aOZX8KVI=
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2972/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Send complete SETTINGS (#2972)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d5b007ef249d_32093fc3aeacd968256455"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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: Mon, 19 Aug 2019 20:03:23 -0000

> I'm a bit concerned that this says effectively says that it's optional (not RFC 2119 word) for clients to remember SETTINGS when sending early data, because now a server can't assume that a client is using the remembered SETTINGS in early data instead of the default settings.

That should be okay, because the defaults are intentionally the most restrictive settings possible.  If the client opts to retain/use a ticket for which it has no settings, then it doesn't get to use anything fancy until it sees the SETTINGS frame.

> Specifically, the text does not update _when_ a SETTINGS frame is expected to be sent.
> If we are to follow the design pattern of HTTP/2, I think that we should clarify that an endpoint MUST send a SETTINGS frame as soon as it becomes possible to send application data, even when the SETTINGS frame would be empty. Otherwise, we should clarify that a SETTINGS frame is to be sent only when one of the following conditions are met: a feature depending on non-default value of a settings parameter is to be used, or a frame other than a SETTINGS frame is to be transmitted on the control stream.

I think this is ultimately intractable.  You can't tell the difference between the control stream having a delay due to packet loss vs. the server simply not sending the settings until it has something else to send, or even not sending it at all.  If either party opts to run on pure defaults, we can't really stop them and getting an empty SETTINGS frame out of them doesn't really solve anything.

We shouldn't mandate a delay, which is how I read your second case.  We can lay down some encouragement to send it ASAP -- getting to use non-default settings in 0-RTT next time and being able to use any features of the control stream both push in that direction -- but failure to do so is probably not obvious and therefore a poor candidate for a MUST.

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