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

fayang <notifications@github.com> Fri, 28 February 2020 00:41 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E853A0A71 for <quic-issues@ietfa.amsl.com>; Thu, 27 Feb 2020 16:41:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yi8DuB3E3rI for <quic-issues@ietfa.amsl.com>; Thu, 27 Feb 2020 16:41:31 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402BA3A0A76 for <quic-issues@ietf.org>; Thu, 27 Feb 2020 16:41:31 -0800 (PST)
Date: Thu, 27 Feb 2020 16:41:30 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1582850490; bh=qGsowozOU2iW8xUTZ//sj1rS9Fn1bFJge6RmxPqeANg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=TD4jYInn1cqDwDD8BjAgsHrSD0Y8xKeXHzHXH5XLD/tUFhuvpU6vR0jUfg0AQ+Lg6 RUqC8g/yz05Ht+62+pk9mCmDrf6l62NiJzT27/0bfOh6opx8YV+BIjbDnAUgy0jjHZ 7RwJ2g4BYGzS2ANfmLae16xvInkwEnH12s5snjCM=
From: fayang <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZI6V556ELP5NNL2W54MWKDVEVBNHHCEHSQ2I@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3486/review/366096553@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3486@github.com>
References: <quicwg/base-drafts/pull/3486@github.com>
Subject: Re: [quicwg/base-drafts] Clarify not arming PTO for ApplicationData before completion (#3486)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e5861ba8956a_4ca23f8515ecd964667c8"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: yangfanud
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/Dhs0J1tu3BG2aIGXZL_7OPHrROQ>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2020 00:41:33 -0000

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

redundant before?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3486#pullrequestreview-366096553