Subject: [quicwg/base-drafts] PTO after handshake completion is not well-defined (#3831)

From: Marten Seemann <[email-masked]>
Date: Tue, 07 Jul 2020 00:28:38 -0700

Assume the following situation: The server sends 0.5-RTT data, but never receives an acknowledgement for that packet. When the handshake completes, the only outstanding packet is that 0.5-RTT packet. The server now needs to arm a PTO timer.

> 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 seems to imply that the timer should be set to `handshake_completion_time + PTO`, whereas 

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

seems to imply that the timer should be set to `outstanding_0.5RTT_packet_sent_time + PTO`.

I think I'd prefer the former interpretation of the latter one. For example, if the entire first flight is lost, the server won't retransmit the Initial for 1s. When the handshake then completes, the RTT is most likely << 1s, which would mean that the timer is set to a time in the past, if we base it on the time the 0.5-RTT packet was sent.

-- 
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/issues/3831

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 07 Jul 2020 14:37:57 -0700

IIUC, what needs to be applied is the latter. The former is merely pointing out that pto_timeout is defined as the minimum of `time_of_last_ack_eliciting_packet[space] + duration` among all the PN spaces, and therefore that it needs to be recalculated when PN spaces are discarded.

> For example, if the entire first flight is lost, the server won't retransmit the Initial for 1s. When the handshake then completes, the RTT is most likely << 1s, which would mean that the timer is set to a time in the past, if we base it on the time the 0.5-RTT packet was sent.

Generally speaking, I think that this is the correct behavior. If an endpoint has sent a tail, and has not received an ACK for more than 1 RTT + alpha from the moment it sent the packet, it is natural to assume that the packet might have been lost. There is no problem in the endpoint realizing that it should send a probe immediately, when the quality of the RTT estimate improves.

That said, I do see problem with sending a PTO when the peer is possibly stuck in calculating the traffic keys; see #3821.

-- 
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/issues/3831#issuecomment-655149228

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Jul 2020 17:48:33 -0700

So, @kazuho is your assertion that in this case you would unblock the sending of PTO, notice that the time has passed, and send a probe immediately?

-- 
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/issues/3831#issuecomment-655214583

---

From: Marten Seemann <[email-masked]>
Date: Tue, 07 Jul 2020 18:02:18 -0700

> Generally speaking, I think that this is the correct behavior. If an endpoint has sent a tail, and has not received an ACK for more than 1 RTT + alpha from the moment it sent the packet, it is natural to assume that the packet might have been lost. 

The problem is that this is not a "real" tail. It's only a tail because we have different packet number spaces. Note that the server completes the handshake when receiving the CFIN, which is also when it derives the client 1-RTT secret. This means there's no way it could have received and processed an ACK for any 1-RTT packet.

-- 
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/issues/3831#issuecomment-655218336

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 07 Jul 2020 19:44:33 -0700

@martinthomson Yes.

@marten-seemann 
> The problem is that this is not a "real" tail. It's only a tail because we have different packet number spaces. Note that the server completes the handshake when receiving the CFIN, which is also w…

I would point out that the example is a corner case. It is about the first flight of the server getting lost, then the first set of PTO probes reaching the client. The assumption is that there were some 0.5 RTT data in the first flight but none in the first set of PTO probes.

While that could happen in practice, as the amount of data the server is allowed to send is different between the two occasions, I would point out that the amount of Initial and Handshake data could be less than the amount of data you could send as a PTO probe (e.g., when resuming a connection or when certificate compression is used). In such case, the server would be sending 0.5 RTT data in the first PTO event. I think that is a fine thing to do.

To paraphrase, the example is about the server sending 0.5 RTT probes than it could have, due to the space of probes being restricted. That's why I do not think it's important to consider about the example.

As previously stated, I do think that there is are issues regarding the interaction of handshake and PTO probes, but my point is that there is nothing wrong with how the PTO timeout is being calculated.

-- 
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/issues/3831#issuecomment-655247801

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 08 Jul 2020 02:45:43 -0700

Discussed the issue offline, @marten-seemann and I think that there is a strong example that does not involve multiple PN spaces. Consider the following case:
* endpoint sends Initial
* after 1 second, endpoint sends Initial (PTO)
* after 1ms, the endpoint receives an ACK for Initial (PTO)

At this point, the endpoint would declare persistent congestion because the duration of congestion (1 seconds) is greater than the threshold (i.e. `(smoothed_rtt + 4 * rttvar + max_ack_delay) * kPersistentCongestionThreshold` where smoothed_rtt is 1ms, rttvar is 1ms, and max_ack_delay is zero).

The problem is that determining persistent congestion based on SRTT is not a good idea until the RTT estimate becomes stable.

I think the easiest fix (which is beneficial at this late stage) would be to disable persistent congestion until the handshake concludes.

-- 
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/issues/3831#issuecomment-655413052

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 14 Jul 2020 21:32:48 -0700

Reconsidering the original point, is the assumption that persistent congestion period is calculated per PN space?

The question is if that assumption has been the intent of the specification. Pseudo-code might imply that (as `AreAllPacketsLost` takes `lost_packets` - a per-PN-space value - as an argument), but I do not see any mention regarding PN space in the text itself.

-- 
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/issues/3831#issuecomment-658539363

---

From: ianswett <[email-masked]>
Date: Sun, 26 Jul 2020 11:51:11 -0700

As commented elsewhere, persistent congestion is a feature of the congestion controller, so it's across all PN spaces.

I also agree with @kazuho that the current text indicates setting the alarm to outstanding_0.5RTT_packet_sent_time + PTO.

Only in the case of no in-flight packets is Now(in this case handshake_completion_time) used.

I actually think the existing text doesn't imply you'd start from then handshake completion time, but I can write an editorial PR to make it completely clear.

-- 
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/issues/3831#issuecomment-664026240

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 Jul 2020 20:41:32 +0000 (UTC)

Closed #3831 via #3959.

-- 
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/issues/3831#event-3605713501