Subject: [quicwg/base-drafts] Timer interval for retire the connection IDs (#3215)

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 11 Nov 2019 09:49:49 -0800

This could be linked to #2130?

/Failing to
   retire the connection IDs within approximately one PTO can cause
   packets to be delayed, lost, or cause the original endpoint to send a
   stateless reset in response to a connection ID it can no longer route
   correctly./ 
- I am unsure what was intended : I’ll argue this is the wrong period and that one PTO interval seems like it could be small to me. To me, the PTO is an estimate of the likely response time of the remote endpoint - that’s an effective period to commence a retransmission or stimulate a probe/refresh. Sending a stateless reset is not a minor event, and as such be tolerant to MSL or at least what in TCP is the RTO. In addition,  I don’t have a precise understanding of “route” in this context, and expected something about the path rather than these words?

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 11 Nov 2019 12:43:47 -0800

It's tied up in why you would retire CIDs.  Various conditions mean that a CID issuer's infrastructure might no longer be able to honor old CIDs (i.e. recognize them as valid and get them to the correct recipient).  However, you usually either know that's coming or can extend the period with some temporary extra state.

The CID issuer will stop accepting the CIDs in question 3 PTO after sending the frame requesting retirement.  That 3-PTO period covers transit time to the peer, any time the peer decides to wait before it stops using the old CIDs, the return transit time for any packets that were already in flight before the peer stopped, and any extra time those packets might have been delayed.  If packets arrive late, they will not be processed and will generate stateless resets.  Those shouldn't be connection-fatal; if the peer has dropped the CIDs and corresponding tokens correctly, then they won't recognize the stateless resets as matching the current connection and will drop *them*.  But you've caused packet "loss" in excess of what happened on the network if you let it get to that point.

This is advice that the peer not wait more than 1 PTO, to make it likely that the issuer is not still receiving packets with old CIDs after the 3-PTO timer has expired.  It's an arbitrary period, no doubt, but it's a better arbitrary period than anything else we've come up with.  Alternative suggestions welcome.

-- 
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/3215#issuecomment-552607316

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Nov 2019 13:34:01 -0800

Now that I see this all written down like this, I wonder whether we should be insisting on the issuer waiting for acknowledgment first.

-- 
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/3215#issuecomment-552626290

---

From: Mike Bishop <[email-masked]>
Date: Mon, 11 Nov 2019 13:58:43 -0800

Waiting for the retirement, or waiting for the ACK of the NCID frame that carried the demand for retirement?

-- 
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/3215#issuecomment-552635359

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Nov 2019 15:04:32 -0800

Before starting any timer.  At least that way any propagation of the request to retire is taken out of consideration.

-- 
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/3215#issuecomment-552657167

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 11 Nov 2019 15:27:22 -0800

The text itself around 1PTO is just a general note of "if you don't retire then your traffic might stop working". Would it be better to remove the specifics of 1PTO (then the 3PTO timer can either wait for ACK or not)?

-- 
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/3215#issuecomment-552664046

---

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Nov 2019 09:06:16 -0800

In the other place, it just says "SHOULD... in a timely manner," but there's some value in defining what constitutes "timely."

-- 
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/3215#issuecomment-552989112

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 12 Nov 2019 09:51:40 -0800

I might argue that the 3 PTO suggestion for the issuer makes sense. We need some guidance for the issuer that is easy to implement and also tolerant to reordering. 3 PTO is a good fit for that.

The question IMO is if we need something more than that. It might be possible to argue that the current recommendation of 1 PTO is a rough derivation of the 3 PTO rule, but it's confusing.

Maybe something like "SHOULD ... in a timely manner, as the issuer of the CIDs might drop the retired CIDs as early as 3 PTO" would be enough.

-- 
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/3215#issuecomment-553011062