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

Kazuho Oku <> Sat, 26 October 2019 08:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 660B212004C for <>; Sat, 26 Oct 2019 01:42:39 -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 is_TXjqMQyVW for <>; Sat, 26 Oct 2019 01:42:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95F0D12006E for <>; Sat, 26 Oct 2019 01:42:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C743A6A1A50 for <>; Sat, 26 Oct 2019 01:42:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572079356; bh=7vH+cKN+A5Ekj0QlSpIz83b51ETWY2HJxnY5ozHkp2k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=klfFZv4LhwbUTB9eoYFujHfFuvzd5W7lMyINe/WqyieBuhy/k8ibFB6e51TArhGBv 22M2xoGgw+9XzUvUVkpnJI3htNd0MqgwVWNbsIcJ135XfW56b/MyVNnZek4RlQoa2y 950z3RuwjXUHX8tX+VsieRj1r/3hcZhKL9ViKrDg=
Date: Sat, 26 Oct 2019 01:42:36 -0700
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3145/review/>
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_5db406fcb866b_309f3f8f834cd96473764"; 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: Sat, 26 Oct 2019 08:42:39 -0000

kazuho commented on this pull request.

> @@ -760,14 +756,9 @@ and ignoring any outstanding Initial packets.
 ### Discarding Handshake Keys
-An endpoint MUST NOT discard its handshake keys until the TLS handshake is
-confirmed ({{handshake-confirmed}}).  An endpoint SHOULD discard its handshake
-keys as soon as it has confirmed the handshake.  Most application protocols
-will send data after the handshake, resulting in acknowledgements that allow
-both endpoints to discard their handshake keys promptly.  Endpoints that do
-not have reason to send immediately after completing the handshake MAY send
-ack-eliciting frames, such as PING, which will cause the handshake to be
-confirmed when they are acknowledged.
+An endpoint MUST discard its handshake keys when the TLS handshake is confirmed
+({{handshake-confirmed}}).  The server MUST send a HANDSHAKE_DONE frame within
+one round-trip time of handshake completion.

> If the server is sending HANDSHAKE_DONE, isn't it no longer 0.5RTT data?

Yes. This is 1 RTT, *not* 0.5 RTT.

Regarding when HANDSHAKE_DONE should be sent, my view is that it HANDSHAKE_DONE is essentially an ACK for the Handshake packet. Based on that view, I do not see a reason why it should be sent at a different timing than other acks for Handshake packets (i.e. send immediately, though an endpoint might wait for a short amount of time to bundle ACK with some other data).

In practice, there is no reason to delay the emission of HANDSHAKE_DONE as much as 1 RTT in HTTP/3. The server should be sending HANDSHAKE_DONE at an early moment for letting the client know that the handshake is done before the client retransmits CF, doing so has a higher probability of having CWND increased at an earlier point. 

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