Subject: [quicwg/base-drafts] Handling of Retire Prior To field (#3046)

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Sep 2019 09:20:39 -0700

At the moment, [section 5.1.2](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.5.1.2) states, quote: _Upon receipt, the peer SHOULD retire the corresponding connection IDs and send the corresponding RETIRE_CONNECTION_ID frames in a timely manner. Failing to do so 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._

As the text uses "SHOULD" rather than a "MUST", some view it as an optional requirement to switch to using a new connection ID in such a situation. Others think that it is a mandatory requirement for an endpoint to switch to a new connection ID.

If we are to consider the latter behavior to be the case, I think the text should better be changed to "**MUST** retire the corresponding connection IDs and send the corresponding RETIRE_CONNECTION_ID frames in a timely manner".

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

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Sep 2019 09:50:20 -0700

My personal take is that it would be nice if the processing of NEW_CONNECTION_ID frame and RETIRE_CONNECTION_ID frame can be an optional feature. QUIC is already very complex, and it would be beneficial to have some features being optional, in sense that endpoints can simply discard certain frames when not implementing certain features.

IIUC, at the moment, these two frames are optional for an endpoint that do not support migration.

OTOH, from the robustness viewpoint of the protocol, it does make sense to change the text to MUST. We might have already crossed the river by introducing the Retire Prior To field.

The third option is to add a TP that indicates if an endpoint supports retirement of 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/3046#issuecomment-532305468

---

From: Nick Banks <[email-masked]>
Date: Tue, 17 Sep 2019 09:55:16 -0700

There was a lot of discussion when the Retire Prior To feature was added. At the time, I felt it pretty clear that it could not be optional from our server's perspective. I agree the sentence with the SHOULD, if read in isolation, could be interpreted as making the feature as optional. But the sentence immediately following it makes it pretty clear that it's not option.

> Failing to do so 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 understand the desire to make things optional for simplicity's sake, but a primary point of this feature, when it was added, was that is was required. Making it optional now would, IMO, defeat the purpose of the feature.

-- 
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/3046#issuecomment-532307370

---

From: ianswett <[email-masked]>
Date: Tue, 17 Sep 2019 09:57:59 -0700

My understanding is that this is optional in the sense GOAWAY is optional.  At some point, the connection is likely to terminate abruptly if you don't follow the request.

-- 
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/3046#issuecomment-532308478

---

From: Nick Banks <[email-masked]>
Date: Tue, 17 Sep 2019 10:02:17 -0700

That's one way to look at it. The difference here is that we're not trying to kill the connection with Retire Prior To.

-- 
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/3046#issuecomment-532310133

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 17 Sep 2019 12:52:11 -0700

There was definitely lots of discussion around the requirement level here when this was added (see #2645), @nibanks asked: 
> why couldn't we make it a "MUST immediately retire" instead of a SHOULD? What reasons would an endpoint have to ACK the packets but not retire the CIDs at the same time?

There was good discussion following that ([start here](https://github.com/quicwg/base-drafts/issues/2645#issuecomment-499180920) and scroll down). 

My understanding of [where we ended up](https://github.com/quicwg/base-drafts/issues/2645#issuecomment-501041204) was that the endpoint being asked to retire a CID really SHOULD retire it or else the peer may stop responding to that CID. 

After the endpoint requesting retirement gives up on a CID and forgets about it, packets will either arrive with that CID or they will not. It has two choices, it can choose to process them if they arrive with the wrong CID, or it can drop them. The enforcement mechanism here is to stop processing the "bad" CIDs, not close the connection, especially as you take into account potentially delayed-but-valid packets.

I think the current stance of "really SHOULD stop using such a CID, but the other endpoint needs to be careful about enforcing that" is the right one, if there's a wording update that would help with understanding there, then it would be great to update the wording as an editorial issue.

-- 
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/3046#issuecomment-532375257

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Sep 2019 18:22:25 -0700

Whatever the answer here, the SHOULD was chosen because "timely manner" isn't defined in a testable fashion.  If someone wants to argue for MUST, then we need a firmer definition of the reaction.

-- 
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/3046#issuecomment-532477898

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Sep 2019 18:24:27 -0700

And to agree with @erickinnear, the squishiness here only exists up until the point that this is "do this or else".  We should make it clearer that the cost of non-compliance is losing the connection.  Not always, but a endpoint is entitled to cut and run if their peer doesn't comply.

-- 
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/3046#issuecomment-532478272

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 18 Sep 2019 00:20:40 -0700

@erickinnear Thank you for the explanation and the links. They help a lot in understanding how we ended up here.

> Whatever the answer here, the SHOULD was chosen because "timely manner" isn't defined in a testable fashion. If someone wants to argue for MUST, then we need a firmer definition of the reaction.

Yeah we already state that "_an endpoint MAY discard a connection ID for which retirement has been requested once an interval of no less than 3 PTO has elapsed since an acknowledgement is received for the NEW_CONNECTION_ID frame requesting that retirement._" So I think it's testable.

Considering that we have a MAY on the side that initiates the retirement, I think we can have a MUST on the receiver side (assuming that we want to).

-- 
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/3046#issuecomment-532555231

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Sep 2019 04:06:19 -0700

That almost works, except that PTO isn't a shared variable.  It's subjective and so endpoints might disagree on where this line is.  At 3PTO, that's probably not a disagreement worth having, but you are effectively recommending instant compliance if you set the bar that low, as packet loss on any packet sent that attempts to comply might cause it to take up to 3PTO to get through.

-- 
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/3046#issuecomment-532635972

---

From: Mike Bishop <[email-masked]>
Date: Mon, 30 Sep 2019 10:59:30 -0700

IIRC, the base of the SHOULD was that we didn't have a specific timeout anyone felt comfortable enforcing in the absence of shared timers between peers.  We've had a general principle that requirements you can't tell whether the peer violated are probably SHOULDs instead of MUSTs.  As Nick says, the SHOULD is intended to refer to doing so promptly, not to doing so at all.

-- 
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/3046#issuecomment-536677973