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

Kazuho Oku <> Tue, 20 August 2019 00:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8BA99120045 for <>; Mon, 19 Aug 2019 17:50:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.898
X-Spam-Status: No, score=-7.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_32=0.001, 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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kY0vKPwaVIcv for <>; Mon, 19 Aug 2019 17:50:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B5A34120154 for <>; Mon, 19 Aug 2019 17:50:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0817A660DBC for <>; Mon, 19 Aug 2019 17:50:34 -0700 (PDT)
Date: Mon, 19 Aug 2019 17:50:33 -0700
From: Kazuho Oku <>
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_5d5b43d9ec1cf_4f333fd551acd968325c6"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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, 20 Aug 2019 00:50:37 -0000

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

I disagree. If we are to require endpoints to send SETTINGS frame right after the connection is established, not sending anything until receiving the SETTINGS frame is a totally acceptable behavior (even though it might be less performant in some cases). It is no different than waiting for a Handshake packet before becoming possible to process a 1-RTT packet.

I think we should clarify if an endpoint can be implemented that way, because we have seen interop issues due to some doing that, and because that is the way H2 is designed. Maybe something like

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