Subject: [quicwg/base-drafts] Recovery: Execute the previously unarmed PTO to avoid a deadlock (#4830)

From: ianswett <[email-masked]>
Date: Tue, 23 Feb 2021 08:00:39 -0800

When the PTO is not armed due to the amplification limit and then a packet is received: https://tools.ietf.org/html/draft-ietf-quic-recovery-34#section-6.2.2, it's important to send data for the PN spaces the PTO is armed for(Initial or Handshake) prior to new application data.

Typically PTO suggests writing new data instead of retransmitting data which may or may not be lost, but that's not true during the handshake.

This is only an issue for the server, since it's caused by enforcing the amplification limits prior to address 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/issues/4830

---

From: Nick Banks <[email-masked]>
Date: Tue, 23 Feb 2021 08:22:58 -0800

I went and double checked the msquic code [here](https://github.com/microsoft/msquic/blob/v1.0.0-129524/src/core/path.c#L96), and we always re-enable the loss detection timer when we become "unblocked" by amplification protection logic. I thought this logic was already driven by some statement in the spec.

I just went back and found this:

> A.6.  On Receiving a Datagram
> 
>    When a server is blocked by anti-amplification limits, receiving a
>    datagram unblocks it, even if none of the packets in the datagram are
>    successfully processed.  In such a case, the PTO timer will need to
>    be re-armed.

Do we need any more than this?

-- 
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/4830#issuecomment-784323998

---

From: ianswett <[email-masked]>
Date: Tue, 23 Feb 2021 08:39:08 -0800

The potential issue is that if the PTO is armed, but should have already expired, it's important to execute it prior to sending any pending data.

I'm working on a PR to make this clearer, and we can whether the extra clarification is necessary?

-- 
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/4830#issuecomment-784335830

---

From: Christian Huitema <[email-masked]>
Date: Tue, 23 Feb 2021 12:15:54 -0800

I wonder whether there is something else going on. Amplification or not, 0-RTT packets can only be acknowledged by ACK frames in 1-RTT packets. Those can only be received after the client gets the 1-rtt keys. So implementation should just start a short timer after the handshake completes.

-- 
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/4830#issuecomment-784481493

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 23 Feb 2021 17:50:57 -0800

This seems like an editorial change, please confirm. Either way, lets ensure @gloinul has an opportunity to comment before landing any changes.

-- 
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/4830#issuecomment-784673615

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 24 Feb 2021 03:12:57 -0800

ngtcp2 has dedicated code for this situation: https://github.com/ngtcp2/ngtcp2/blob/397c943599665f35733b8d703715049be7031618/lib/ngtcp2_conn.c#L8583-L8594

-- 
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/4830#issuecomment-785001926

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 24 Feb 2021 06:03:00 -0800

In response to @LPardue: If the WG establish a consensus on the need for a change a particular fix then this PR can be applied in the AUTH48 with AD approval. 

I think we need to figure out if not merging the PR until AUTH48 is the best? It makes it simple to provide the changes to the RFC-editor, but maybe makes it harder for the rest of the community to keep track of the changes if there are no editors copy that contain all agreed things. However, considering the hopefully limited time that may make sense. 

-- 
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/4830#issuecomment-785096883

---

From: Lars Eggert <[email-masked]>
Date: Wed, 24 Feb 2021 07:12:13 -0800

We can tag the versions that entered the RFC Editor queue, and then generate a diff against those at AUTH48.

-- 
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/4830#issuecomment-785144049

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Feb 2021 12:49:23 -0800

That tag already exists, so we are good.

-- 
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/4830#issuecomment-785373501