Re: [quicwg/base-drafts] use a HANDSHAKE_DONE frame to drive the handshake to confirmation (#3145)

ianswett <> Fri, 25 October 2019 14:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F5B6120810 for <>; Fri, 25 Oct 2019 07:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_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
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I_fMKeowJ5l0 for <>; Fri, 25 Oct 2019 07:05:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE562120123 for <>; Fri, 25 Oct 2019 07:05:42 -0700 (PDT)
Date: Fri, 25 Oct 2019 07:05:42 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572012342; bh=u6hhU5/1hJxs1M88noNiVNcvfc3HFe4hXXYfK6Uu0uo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=XUWOYcMv59YuZSEvuMh2sfJ4w8h6sRuCMcbQhgrTakZ6CKZIgQaq0zEPl/181F8b0 JBKbR3DAHBvvHqPMtfoUhGcBofoJTUsjWzHO1H/lKibJKzKxc6UIm9jTuujFKBKaJ6 D9MK4z/x8nPAWkyAOzVltV0arcOMFSzCAAaSxhL0=
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3145/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] use a HANDSHAKE_DONE frame to drive the handshake to confirmation (#3145)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db30136e731_6bc13fa80facd96415204"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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: Fri, 25 Oct 2019 14:05:44 -0000

> PS. The approach proposed in this PR has the following two properties:
> * sending one-way signal from to the client, when the server reaches handshake complete
> * use a frame as the conveyor of the signal
> It's good to see emerging consensus (on the first point), but it seems to me that some are concerned about the second point. Specifically, I see suggestions to use a continuous signal ([#3145 (comment)](, or an ACK as a signal too (see [#3145 (comment)](
> **If** we are in fact unhappy with using a frame, then I might suggest using Key Update as the conveyor of the one-way signal. We can require the server to initiate a Key Update when the handshake is complete and to repeatedly send PINGs until it receives an ACK for one of them.
> That'd give us an continuous signal, and also removes the need for an alternative signal. And also the need to have a different frame.

I also had this thought, but flipping the key update bit doesn't force something to be sent until it's acknowledged, which this frame does.  We could do both if we thought it was very important for every packet to have the signal, but I'm not convinced it's worthwhile.

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