Subject: [quicwg/base-drafts] Avoid renewing retired connection IDs (#1799)

From: janaiyengar <[email-masked]>
Date: Tue, 25 Sep 2018 15:30:52 -0700

to avoid a receiver accepting a retransmitted NEW_CONNECTION_ID, after the same connection ID has been retired. This can happen if a receiver receives, uses, and quickly retires a connection ID, but the sender is still retransmitting because it hasn't yet received an acknowledgment for the NEW_CONNECTION_ID frame.

A simple proposal is to add a sequence number to NEW_CONNECTION_ID, which is used in RETIRE_CONNECTION_ID. Then a receiver can easily discard old connection IDs.

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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 25 Sep 2018 15:50:48 -0700

This is basically un-removing #1465.

-- 
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/1799#issuecomment-424527753

---

From: erickinnear <[email-masked]>
Date: Tue, 25 Sep 2018 18:23:17 -0700

If you're going to use the proposal from NYC: 

> Each CID comes with a sequence number, every CID that you send must have a sequence number higher than any you've previously sent

> This does not requiring anything to happen in lockstep as before, however this solves a big edge case in that you can now forget CIDs immediately instead of waiting for 3xRTO when you retire them, since any NEW_CONNECTION_ID frame crossing paths with the retirement frame will contain a sequence number. Instead, you just remember the highest sequence number NEW_CONNECTION_ID that you've RETIRED.

>For example:
Peer sends NEW_CONNECTION_ID and you use it, then immediately retire it with RETIRE_CONNECTION_ID.
Ack of NEW_CONNECTION_ID gets lost.
RETIRE_CONNECTION_ID frame is still in flight when the peer retransmits NEW_CONNECTION_ID.
If you've got a sequence number you can keep track of the highest sequence that you've gotten and, since this one will not advance the sequence number, you can safely ignore the duplicate NEW_CONNECTION_ID frame.

Note the distinction between *received* and *retired* sequence number, since if you keep track of *received* sequence number for dropping new ones, then reordering between NEW_CONNECTION_ID frames can cause you to ignore some of them when you shouldn't. 

-- 
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/1799#issuecomment-424553366

---

From: Igor Lubashev <[email-masked]>
Date: Sun, 30 Sep 2018 09:25:56 -0700

> Note the distinction between received and retired sequence number
When you say "you can keep track of the highest sequence that you've gotten", do you mean the the highest _retired_ sequence number?

If the sender sends you two NEW_CONNECTION_IDs in different packets, and the packets are reordered, and you use and quickly retire the second CID, will you just discard the first CID when you eventually receive it?  That may be a fine decision, as long as it is signaled correctly to the sender.  You would want to immediately send RETIRE_CONNECTION_ID for each CID you are discarding.

-- 
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/1799#issuecomment-425732807