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 1819A3A0BA7
 for <quic-issues@ietfa.amsl.com>; Tue, 28 Jul 2020 12:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.101
X-Spam-Level: 
X-Spam-Status: No, score=-3.101 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, RCVD_IN_MSPIKE_H2=-0.001,
 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 eeh9YAwrcMJm for <quic-issues@ietfa.amsl.com>;
 Tue, 28 Jul 2020 12:36:18 -0700 (PDT)
Received: from out-21.smtp.github.com (out-21.smtp.github.com [192.30.252.204])
 (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 6B57F3A0BA1
 for <quic-issues@ietf.org>; Tue, 28 Jul 2020 12:36:18 -0700 (PDT)
Received: from github-lowworker-3a0df0f.ac4-iad.github.net
 (github-lowworker-3a0df0f.ac4-iad.github.net [10.52.25.92])
 by smtp.github.com (Postfix) with ESMTP id 28C6E520EA0
 for <quic-issues@ietf.org>; Tue, 28 Jul 2020 12:36:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com;
 s=pf2014; t=1595964977;
 bh=x3Urj3NheO5NHya1RzElRpP9xe7VP4kLdbN/bxYQbpA=;
 h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID:
 List-Archive:List-Post:List-Unsubscribe:From;
 b=UmQwscVoy1l3/gIngl3HjtifgN8IB0lP1gBk76ngwi+ClcylpUJ3cUB9f6irLCh1J
 J9XdbW63INW7hEWq4oLuko31VOmI9Z08OWzd4sWOHtB+Cu0kZk4nv0Z+zI52+CjpR3
 qmPYV9H6iXzXHkhDSBHzbzEUL8zGCFawEfMOm29s=
Date: Tue, 28 Jul 2020 12:36:17 -0700
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+AFTOJKY2524PHMKKGXG6A655FRPTDEVBNHHCPL7SKU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3959/review/456921344@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3959@github.com>
References: <quicwg/base-drafts/pull/3959@github.com>
Subject: Re: [quicwg/base-drafts] When is the PTO armed from? (#3959)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5f207e311962f_49a616f823369e";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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/KbHA3S_REwqXW95vqn2PKfRlW20>
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: Tue, 28 Jul 2020 19:36:21 -0000


----==_mimepart_5f207e311962f_49a616f823369e
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

@janaiyengar commented on this pull request.

A couple of suggestions

> @@ -519,8 +519,9 @@ immediately.
 A sender recomputes and may need to reset its PTO timer every time an
 ack-eliciting packet is sent or acknowledged, when the handshake is confirmed,
 or when Initial or Handshake keys are discarded. This ensures the PTO is always
-set based on the latest RTT information and for the last sent packet in the
-correct packet number space.
+set based on the latest RTT information and for the last sent ack-eliciting
+packet in the correct packet number space. When the PTO expires and there are
+no ack-eliciting packets in flight, the PTO is set from the current time.

```suggestion
no ack-eliciting packets in flight, the PTO is set from that moment.
```

> @@ -591,15 +592,10 @@ client, it is the client's responsibility to send packets to unblock the server
 until it is certain that the server has finished its address validation
 (see Section 8 of {{QUIC-TRANSPORT}}).  That is, the client MUST set the
 probe timer if the client has not received an acknowledgement for one of its
-Handshake or 1-RTT packets, and has not received a HANDSHAKE_DONE frame.
-If Handshake keys are available to the client, it MUST send a Handshake
-packet, and otherwise it MUST send an Initial packet in a UDP datagram of
-at least 1200 bytes.
-
-A client could have received and acknowledged a Handshake packet, causing it to
-discard state for the Initial packet number space, but not sent any
-ack-eliciting Handshake packets.  In this case, the PTO timer is armed from the
-time that the Initial packet number space is discarded.
+Handshake or 1-RTT packets, and has not received a HANDSHAKE_DONE frame,

```suggestion
Handshake or 1-RTT packets and has not received a HANDSHAKE_DONE frame,
```

> +even if there are no packets in flight. If Handshake keys are available to the
+client, it MUST send a Handshake packet, and otherwise it MUST send an Initial
+packet in a UDP datagram of at least 1200 bytes.

```suggestion
even if there are no packets in flight. When the PTO fires, the client MUST
send a Handshake packet if it has Handshake keys, otherwise it MUST
send an Initial packet in a UDP datagram of at least 1200 bytes.
```

-- 
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/3959#pullrequestreview-456921344
----==_mimepart_5f207e311962f_49a616f823369e
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p></p>=0D
<p><b>@janaiyengar</b> commented on this pull request.</p>=0D
=0D
<p>A couple of suggestions</p><hr>=0D
=0D
<p>In <a href=3D"https://github.com/quicwg/base-drafts/pull/3959#discussi=
on_r461804233">draft-ietf-quic-recovery.md</a>:</p>=0D
<pre style=3D'color:#555'>&gt; @@ -519,8 +519,9 @@ immediately.=0D
 A sender recomputes and may need to reset its PTO timer every time an=0D=

 ack-eliciting packet is sent or acknowledged, when the handshake is conf=
irmed,=0D
 or when Initial or Handshake keys are discarded. This ensures the PTO is=
 always=0D
-set based on the latest RTT information and for the last sent packet in =
the=0D
-correct packet number space.=0D
+set based on the latest RTT information and for the last sent ack-elicit=
ing=0D
+packet in the correct packet number space. When the PTO expires and ther=
e are=0D
+no ack-eliciting packets in flight, the PTO is set from the current time=
.=0D
</pre>=0D
=E2=AC=87=EF=B8=8F Suggested change=0D
<pre style=3D"color: #555">-no ack-eliciting packets in flight, the PTO i=
s set from the current time.=0D
+no ack-eliciting packets in flight, the PTO is set from that moment.=0D
</pre>=0D
=0D
=0D
<hr>=0D
=0D
<p>In <a href=3D"https://github.com/quicwg/base-drafts/pull/3959#discussi=
on_r461805593">draft-ietf-quic-recovery.md</a>:</p>=0D
<pre style=3D'color:#555'>&gt; @@ -591,15 +592,10 @@ client, it is the cl=
ient&#39;s responsibility to send packets to unblock the server=0D
 until it is certain that the server has finished its address validation=0D=

 (see Section 8 of {{QUIC-TRANSPORT}}).  That is, the client MUST set the=
=0D
 probe timer if the client has not received an acknowledgement for one of=
 its=0D
-Handshake or 1-RTT packets, and has not received a HANDSHAKE_DONE frame.=
=0D
-If Handshake keys are available to the client, it MUST send a Handshake=0D=

-packet, and otherwise it MUST send an Initial packet in a UDP datagram o=
f=0D
-at least 1200 bytes.=0D
-=0D
-A client could have received and acknowledged a Handshake packet, causin=
g it to=0D
-discard state for the Initial packet number space, but not sent any=0D
-ack-eliciting Handshake packets.  In this case, the PTO timer is armed f=
rom the=0D
-time that the Initial packet number space is discarded.=0D
+Handshake or 1-RTT packets, and has not received a HANDSHAKE_DONE frame,=
=0D
</pre>=0D
=E2=AC=87=EF=B8=8F Suggested change=0D
<pre style=3D"color: #555">-Handshake or 1-RTT packets, and has not recei=
ved a HANDSHAKE_DONE frame,=0D
+Handshake or 1-RTT packets and has not received a HANDSHAKE_DONE frame,=0D=

</pre>=0D
=0D
=0D
<hr>=0D
=0D
<p>In <a href=3D"https://github.com/quicwg/base-drafts/pull/3959#discussi=
on_r461823420">draft-ietf-quic-recovery.md</a>:</p>=0D
<pre style=3D'color:#555'>&gt; +even if there are no packets in flight. I=
f Handshake keys are available to the=0D
+client, it MUST send a Handshake packet, and otherwise it MUST send an I=
nitial=0D
+packet in a UDP datagram of at least 1200 bytes.=0D
</pre>=0D
=E2=AC=87=EF=B8=8F Suggested change=0D
<pre style=3D"color: #555">-even if there are no packets in flight. If Ha=
ndshake keys are available to the=0D
-client, it MUST send a Handshake packet, and otherwise it MUST send an I=
nitial=0D
-packet in a UDP datagram of at least 1200 bytes.=0D
+even if there are no packets in flight. When the PTO fires, the client M=
UST=0D
+send a Handshake packet if it has Handshake keys, otherwise it MUST=0D
+send an Initial packet in a UDP datagram of at least 1200 bytes.=0D
</pre>=0D
=0D
=0D
<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m=
dash;<br />You are receiving this because you are subscribed to this thre=
ad.<br />Reply to this email directly, <a href=3D"https://github.com/quic=
wg/base-drafts/pull/3959#pullrequestreview-456921344">view it on GitHub</=
a>, or <a href=3D"https://github.com/notifications/unsubscribe-auth/AFTOJ=
K6NGOWZG6SYWS2ELMDR54SDDANCNFSM4PIDYHNA">unsubscribe</a>.<img src=3D"http=
s://github.com/notifications/beacon/AFTOJK7N3O4ETQ6F5L4X2G3R54SDDA5CNFSM4=
PIDYHNKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZ=
GODM6BCAA.gif" height=3D"1" width=3D"1" alt=3D"" /></p>=0D
<script type=3D"application/ld+json">[=0D
{=0D
"@context": "http://schema.org",=0D
"@type": "EmailMessage",=0D
"potentialAction": {=0D
"@type": "ViewAction",=0D
"target": "https://github.com/quicwg/base-drafts/pull/3959#pullrequestrev=
iew-456921344",=0D
"url": "https://github.com/quicwg/base-drafts/pull/3959#pullrequestreview=
-456921344",=0D
"name": "View Pull Request"=0D
},=0D
"description": "View this Pull Request on GitHub",=0D
"publisher": {=0D
"@type": "Organization",=0D
"name": "GitHub",=0D
"url": "https://github.com"=0D
}=0D
}=0D
]</script>=

----==_mimepart_5f207e311962f_49a616f823369e--

