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

From: Lars Eggert <[email-masked]>
Date: Wed, 05 Feb 2020 01:47:28 -0800

Discussed in ZRH. Proposed resolution is to talk it over over lunch.

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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 05 Feb 2020 03:05:50 -0800

To me it seems that there is confusion regarding what "retire" means.

I'd argue that when receiving a NCID frame carrying a retirement request, the receiver can promptly stop using CIDs that are to be retired, and stop recognizing the Stateless Reset Tokens that are associated with the CIDs being retired. At the same time, it could well be the case that the receiver might not be able to send RETIRE_CONNECTION_ID frames at that point (due to CWND being restricted, etc.).

Considering this, I think what we should do is be clear about the distinction. To be precise we can change the following existing text:
> Upon receipt, the peer MUST first retire the corresponding connection IDs using RETIRE_CONNECTION_ID frames and then add the newly provided connection ID to the set of active connection IDs. Failure 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.

to:
> Upon receipt, the peer MUST promptly stop using the corresponding connection IDs and stop recognizing Stateless Reset Tokens associated with those connection IDs. Failure to doing so 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. After stopping use of those connection IDs and Stateless Reset Tokens, the receiver MUST send RETIRE_CONNECTION_ID frames to indicate the peer that those have been retired.

We can also change the 1PTO and 3PTO requirement, but I do not see a reason.

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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 05 Feb 2020 05:05:09 -0800

Discussed in ZRH. Proposed resolution is to close with no action. In addition, potential new Editorial issue to clean up existing text. Discussion on removing Retire-Prior-To is in #3420.

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 05 Feb 2020 05:21:52 -0800

@kazuho:  The reason for "first retire... and then...." is to enable working within the CID limit.  If you're at the limit already, the server can ask you to retire everything and give you a new one.  That does mean there are "limit + 1" CIDs outstanding at that time.  Looks like Martin has opened #3422 to make this clearer.

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