Subject: [quicwg/base-drafts] Clarify when the PTO may need to be recomputed and reset (#3665)

From: ianswett <[email-masked]>
Date: Mon, 18 May 2020 03:27:27 -0700

Clarifies the cases when the PTO needs to be recomputed and possibly reset.  This was not in a single place before.

Fixes #3613
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3665

-- Commit Summary --

  * Clarify when the PTO may need to be recomputed and reset

-- File Changes --

    M draft-ietf-quic-recovery.md (32)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3665.patch
https://github.com/quicwg/base-drafts/pull/3665.diff

-- 
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/3665

---

From: martinduke <[email-masked]>
Date: Mon, 18 May 2020 13:01:22 -0700

@martinduke commented on this pull request.

 When a PTO timer expires, the PTO backoff MUST be increased, resulting in the
-PTO period being set to twice its current value.  The PTO period is set based
-on the latest RTT information after receiving an acknowledgement. The PTO
-backoff is reset upon receiving an acknowledgement unless it's a client unsure
-if the the server has validated the client's address. Not resetting the backoff
-during peer address validation ensures the client's anti-deadlock timer is not
-set too aggressively when the server is slow in responding with handshake data.
+PTO period being set to twice its current value. The PTO backoff is reset upon
+receiving an acknowledgement unless it's a client unsure if the the server has

s/the the/the

-- 
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/3665#pullrequestreview-413899983

---

From: ianswett <[email-masked]>
Date: Mon, 18 May 2020 13:43:55 -0700

@ianswett pushed 1 commit.

40e8c84ee5d29983a860f5fe1fc88c0387382a4c  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3665/files/32ee54571d322a19c4442333f941d0bc233dbca6..40e8c84ee5d29983a860f5fe1fc88c0387382a4c

---

From: martinduke <[email-masked]>
Date: Mon, 18 May 2020 13:49:12 -0700

@martinduke approved this pull request.

-- 
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/3665#pullrequestreview-413928678

---

From: Martin Thomson <[email-masked]>
Date: Mon, 18 May 2020 17:53:34 -0700

@martinthomson commented on this pull request.

+receiving an acknowledgement unless it's a client unsure if the server has

The subject of the "it" is a little unclear here.

Perhaps instead:

> The PTO backoff is reset when receiving an acknowledgment, except when a client receives an acknowledgment from a server prior to the server validating the client address.  A client MUST keep increasing the PTO count until <insert clear conditions here>.

 When a PTO timer expires, the PTO backoff MUST be increased, resulting in the
-PTO period being set to twice its current value.  The PTO period is set based
-on the latest RTT information after receiving an acknowledgement. The PTO
-backoff is reset upon receiving an acknowledgement unless it's a client unsure
-if the the server has validated the client's address. Not resetting the backoff
-during peer address validation ensures the client's anti-deadlock timer is not
-set too aggressively when the server is slow in responding with handshake data.
+PTO period being set to twice its current value. The PTO backoff is reset upon
+receiving an acknowledgement unless it's a client unsure if the server has
+validated the client's address. Not resetting the backoff during peer address
+validation ensures the client's anti-deadlock timer is not set too aggressively

This is the first use of anti-deadlock in the draft.  I think that you are just referring to the PTO timer that we set unconditionally on the client prior to address validation.

It might be better to keep all the rules about setting the "PTO timer" at the client prior to address validation in the one paragraph/section rather than scattering them about like this.  Then you can say "except at the client prior to address validation; see {{...}}".

-- 
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/3665#pullrequestreview-414029312

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 18 May 2020 19:27:31 -0700

@janaiyengar commented on this pull request.

> @@ -513,22 +513,26 @@ The PTO value MUST be set to at least kGranularity, to avoid the timer expiring
 immediately.
 
 A sender recomputes and may need to reset its PTO timer every time an
-ack-eliciting packet is sent. 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 prevents a client from retransmitting a 0-RTT
-packet on a PTO expiration before confirming that the server is able to decrypt
-0-RTT packets, and prevents a server from sending a 1-RTT packet on a PTO
-expiration before it has the keys to process an acknowledgement.
+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.
+
+When ack-eliciting packets are in-flight in multiple packet number spaces,

```suggestion
When ack-eliciting packets in multiple packet number spaces are in flight,
```

> +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

```suggestion
the timer MUST be set for the packet number space with the earliest timeout,
with one exception. The ApplicationData packet number space (Section 4.1.1
of {{QUIC-TLS}}) MUST be ignored until the handshake completes. Not arming
the PTO for ApplicationData
```

-- 
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/3665#pullrequestreview-414039925

---

From: ianswett <[email-masked]>
Date: Tue, 19 May 2020 14:02:25 -0700

f9bde12b42fe54fa9fc04a07630d2e0b35103ad8  Apply suggestions from code review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3665/files/40e8c84ee5d29983a860f5fe1fc88c0387382a4c..f9bde12b42fe54fa9fc04a07630d2e0b35103ad8

---

From: ianswett <[email-masked]>
Date: Tue, 19 May 2020 14:02:37 -0700

54659b1e26d41c50df060f617bafc9f4ac3ef201  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3665/files/f9bde12b42fe54fa9fc04a07630d2e0b35103ad8..54659b1e26d41c50df060f617bafc9f4ac3ef201

---

From: ianswett <[email-masked]>
Date: Tue, 19 May 2020 14:11:07 -0700

03d29025efd1146a8688b1b5ab23c10c94644ceb  Martin's suggested reworked

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3665/files/54659b1e26d41c50df060f617bafc9f4ac3ef201..03d29025efd1146a8688b1b5ab23c10c94644ceb

---

From: ianswett <[email-masked]>
Date: Tue, 19 May 2020 14:11:28 -0700

@ianswett commented on this pull request.

SG, I tried to rework this with your suggestion.

-- 
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/3665#discussion_r427602293

---

From: ianswett <[email-masked]>
Date: Tue, 19 May 2020 14:12:53 -0700

a1618e828da8908b4ac8c850b3e9fac9a01e9f2e  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3665/files/03d29025efd1146a8688b1b5ab23c10c94644ceb..a1618e828da8908b4ac8c850b3e9fac9a01e9f2e

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 19 May 2020 15:02:12 -0700

> +PTO period being set to twice its current value. The PTO backoff is reset upon
+receiving an acknowledgement, except when a client receives an acknowledgment
+from a server prior to the server validating the client address. A client
+keeps increasing the PTO backoff until the server's address validation
+completes to ensure the client's PTO timer is not set too aggressively
+when the server is slow in responding with handshake data.

```suggestion
PTO period being set to twice its current value. The PTO backoff factor is reset
when an acknowledgement is received, except in the following case. A server
might take longer to respond to packets during the handshake than otherwise.
To protect such a server from repeated client probes, the PTO backoff is not
reset at a client that is not yet certain that the server has finished validating
the client's address. That is, a client does not reset the PTO backoff factor on
receiving acknowledgements until it receives a HANDSHAKE_DONE frame or
an acknowledgement for one of its Handshake or 1-RTT packets.
```

-- 
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/3665#pullrequestreview-414855227

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 May 2020 15:28:22 -0700

use "handshake confirmed" for the last piece.

-- 
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/3665#discussion_r427636314

---

From: ianswett <[email-masked]>
Date: Tue, 19 May 2020 15:30:36 -0700

An ACK of a Handshake packet isn't handshake confirmed, unfortunately.

-- 
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/3665#discussion_r427637132

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 May 2020 15:54:59 -0700

But that's fine.  This doesn't need to more aggressive than confirmation.

-- 
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/3665#discussion_r427645460

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 19 May 2020 16:20:49 -0700

@janaiyengar pushed 1 commit.

e4919c2b17fa369a7aaa15247437e5eeaddc7712  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3665/files/a1618e828da8908b4ac8c850b3e9fac9a01e9f2e..e4919c2b17fa369a7aaa15247437e5eeaddc7712

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 May 2020 16:21:57 -0700

@martinthomson pushed 1 commit.

21607aed5dde572c10bbe77024eebb168bd7d1ff  reflow

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3665/files/e4919c2b17fa369a7aaa15247437e5eeaddc7712..21607aed5dde572c10bbe77024eebb168bd7d1ff

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 May 2020 16:22:19 -0700

Merged #3665 into master.

-- 
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/3665#event-3354072252

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 19 May 2020 16:22:39 -0700

@ianswett : merging this so it makes -28. Filing a separate issue for the leftover editorial fix.

-- 
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/3665#issuecomment-631138439