Re: [quicwg/base-drafts] Retransmit server initial upon second Initial (#3080)

Mike Bishop <> Mon, 02 March 2020 16:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D9913A0B84 for <>; Mon, 2 Mar 2020 08:48:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Status: No, score=-3.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 Kb4QV1HNwa2A for <>; Mon, 2 Mar 2020 08:48:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6EFDA3A0AD8 for <>; Mon, 2 Mar 2020 08:48:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9444352110D for <>; Mon, 2 Mar 2020 08:48:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1583167700; bh=AXPjI8n4PVdfgdyhNikBUOEoIrtbACQs4RL0Qy4zmgY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=eHzxsfqv0QVAp2zpqV+SXZBN/rcqZgRE/x5Nc29ETxbgm9h1s1nUReCUVM54CiFrx Vi7BQBCGtnl2BmeIhT+eswxn7UF2+ShHZ9ilVEIVOrNTSL3MfdRANHyPlUvD7madNg p7Dx2b5p3vMpqs8jBLZEDIljfjXz+dIriz9mWH5I=
Date: Mon, 02 Mar 2020 08:48:20 -0800
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3080/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Retransmit server initial upon second Initial (#3080)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e5d38d48380f_77153fee8c4cd960355019"; 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, 02 Mar 2020 16:48:28 -0000

MikeBishop commented on this pull request.

> @@ -508,6 +508,12 @@ until it is certain that the server has finished its address validation
 probe timer if the client has not received an acknowledgement for one of its
 Handshake or 1-RTT packets.
+When a server receives duplicate CRYPTO data in an Initial packet after sending
+its Initial flight, it can assume the client did not receive all Initial CRYPTO
+data. To speed handshake completion, it SHOULD retransmit all unacknowledged
+Initial CRYPTO data subject to the path validation limits.  After doing so,
+the PTO is re-armed.

There should never be a duplicate packet number unless the network duplicates packets.  That's not a signal of anything on the client.  I think the intent here is to act if the server receives CRYPTO frames that restate one or more already-received bytes.

> @@ -519,6 +519,24 @@ bytes.
 Initial packets and Handshake packets may never be acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded.
+### Speeding Up Handshake Completion
+When a server receives an Initial packet containing duplicate CRYPTO data,
+it can assume the client did not receive all of the server's CRYPTO data sent
+in Initial packets, or the client's estimated RTT is too small. When a
+client receives Handshake or 1-RTT packets prior to obtaining Handshake keys,
+it may assume some or all of the server's Initial packets were lost.

If you can decrypt them, then clearly the Initial packets you're waiting for weren't lost.

> +Peers can also use coalesced packets to ensure that each datagram elicits at least
+one acknowledgement.  For example, clients can coalesce an Initial packet
+containing PING and PADDING frames with a 0-RTT data packet and a server can
+coalesce an Initial packet containing a PING frame with one or more packets in
+its first flight.

I think what's missing is any description of _why_ an implementation might want to do that except things we don't really want to encourage.  The obvious reading is that clients are tracking whether the datagram was received, inferring that the other packets in that datagram were received but not processed (or processable?), and removing everything in that datagram from bytes-in-flight.  But it doesn't explicitly say that.  I'd either get more explicit, or not make the reference.

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