Re: [quicwg/base-drafts] Clarify not arming PTO for ApplicationData before completion (#3486)

ianswett <> Fri, 28 February 2020 01:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F42173A0C0B for <>; Thu, 27 Feb 2020 17:51:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Status: No, score=-1.696 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_IMAGE_ONLY_28=1.404, 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 w_xiAvXxntws for <>; Thu, 27 Feb 2020 17:51:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 886313A0BF7 for <>; Thu, 27 Feb 2020 17:51:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DFFA86A123E for <>; Thu, 27 Feb 2020 17:51:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1582854671; bh=qOlNw0ns0etUjhO7bfQlndIPw0C9bgOwx4NwDsV5c20=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=FGX5YJGWF3h5CBBYCNgRc4tt89OBOjDvYiejrTMWogAcIXWzLJjD8SYnSHswARoOD cS6Wudn+Je2zawolwM5MpjUj5rYfgGxAS6FNe8Nov2JToCvXLtySyeO5fgH0nMOb3z v3HJJAFggMPlq2yGaiGTblywbQMFBe0zVYQUEauU=
Date: Thu, 27 Feb 2020 17:51:11 -0800
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3486/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Clarify not arming PTO for ApplicationData before completion (#3486)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e58720fcec2a_7d853f87700cd96024854b"; 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, 28 Feb 2020 01:51:21 -0000

ianswett commented on this pull request.

> @@ -476,9 +476,10 @@ When ack-eliciting packets are in-flight in multiple packet number spaces,
 the timer MUST be set for the packet number space with the earliest timeout,
 except for ApplicationData, which MUST be ignored until the handshake
 completes; see Section 4.1.1 of {{QUIC-TLS}}.  Not arming the PTO for
-ApplicationData prioritizes completing the handshake and prevents the server
-from sending a 1-RTT packet on a PTO before before it has the keys to process
-a 1-RTT packet.
+ApplicationData prioritizes completing the handshake, prevents the client
+from sending a 0-RTT packet on a PTO before it knows the server has accepted
+0-RTT, and prevents the server from sending a 1-RTT packet on a PTO before
+before it has the keys to process a 1-RTT acknowledgment.

Fixed, thanks!

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