Subject: [quicwg/base-drafts] Remove timing guidance (#3474)

From: Mike Bishop <[email-masked]>
Date: Fri, 21 Feb 2020 10:35:05 -0800

Removes guidance on specific times in favor of descriptions of what the CID issuer might have to do if it can no longer support outstanding CIDs.

I believe the impact of this is editorial, but I touched normative statements, so if anyone disagrees please scream.

Fixes #3420.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3474

-- Commit Summary --

  * Remove timing guidance

-- File Changes --

    M draft-ietf-quic-transport.md (29)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3474.patch
https://github.com/quicwg/base-drafts/pull/3474.diff

-- 
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/pull/3474

---

From: Nick Banks <[email-masked]>
Date: Fri, 21 Feb 2020 11:50:44 -0800

nibanks approved this pull 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/pull/3474#pullrequestreview-362876789

---

From: Martin Thomson <[email-masked]>
Date: Sat, 22 Feb 2020 15:19:27 -0800

martinthomson requested changes on this pull request.

Thanks for doing this.  I think that it's the right general approach, but I have some things that I'd like to see.

> -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.  Until
-then, the endpoint SHOULD be prepared to receive packets that contain the
-connection ID that it has requested be retired.  Subsequent incoming packets
-using that connection ID could elicit a response with the corresponding
-stateless reset token.
+An endpoint might need to stop accepting previously issued connection IDs in
+certain circumstances.  Such an endpoint can cause its peer to retire connection
+IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To
+field.  The endpoint SHOULD continue to accept the previously issued connection
+IDs until they are retired by the peer.  If the endpoint can no longer process
+the indicated connection IDs, it MAY close the connection.
+
+Upon receipt of an increased Retire Prior To field, the peer MUST first stop
+using the corresponding connection IDs using RETIRE_CONNECTION_ID frames and

pedantic nit: stopping use and sending RETIRE_CONNECTION_ID are two discrete actions.

> -then, the endpoint SHOULD be prepared to receive packets that contain the
-connection ID that it has requested be retired.  Subsequent incoming packets
-using that connection ID could elicit a response with the corresponding
-stateless reset token.
+An endpoint might need to stop accepting previously issued connection IDs in
+certain circumstances.  Such an endpoint can cause its peer to retire connection
+IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To
+field.  The endpoint SHOULD continue to accept the previously issued connection
+IDs until they are retired by the peer.  If the endpoint can no longer process
+the indicated connection IDs, it MAY close the connection.
+
+Upon receipt of an increased Retire Prior To field, the peer MUST first stop
+using 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 promptly can cause failure of the
+connection, either because the endpoint closed the connection or can no longer

"the endpoint" here is ambiguous.

> -connection ID that it has requested be retired.  Subsequent incoming packets
-using that connection ID could elicit a response with the corresponding
-stateless reset token.
+An endpoint might need to stop accepting previously issued connection IDs in
+certain circumstances.  Such an endpoint can cause its peer to retire connection
+IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To
+field.  The endpoint SHOULD continue to accept the previously issued connection
+IDs until they are retired by the peer.  If the endpoint can no longer process
+the indicated connection IDs, it MAY close the connection.
+
+Upon receipt of an increased Retire Prior To field, the peer MUST first stop
+using 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 promptly can cause failure of the
+connection, either because the endpoint closed the connection or can no longer
+associate these connection IDs with the active connection.

I think that you might want to say "Failure to retire connection IDs promptly when requested can result in connection failures as peer might be unable to continue use of the corresponding connection IDs, resulting in either closing the connection or a stateless reset."  Or similar.

-- 
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/pull/3474#pullrequestreview-363055994

---

From: Eric Kinnear <[email-masked]>
Date: Sat, 22 Feb 2020 20:44:09 -0800

erickinnear approved this pull request.

Thanks for writing this up! 

How about: 
```
Upon receipt of an increased Retire Prior To field, the peer MUST stop using the 
corresponding connection IDs and retire them with RETIRE_CONNECTION_ID frames 
before adding the newly provided connection ID to the set of active connection IDs. 
This ordering allows an endpoint that has already supplied its peer with as many 
connection IDs as allowed by the active_connection_id_limit transport parameter 
to replace those connection IDs with new ones as necessary.
```

We'd discussed adding some extra text making it very obvious the point about the ordering enabling replacing a full limit, and having that text might make it easier to reword the first sentence further.

This still loses the idea that it may take a little while to stop using the CIDs (FWIW, I don't think we need to care about that part, the only real requirement here is that you retire them, and if you generate R_CID then you must have drained your outbound processing by the time the frame gets there).

+1 this seems to capture it, otherwise I'd be a bit unsure what "because the endpoint closed the connection" meant and why that was my fault.

-- 
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/pull/3474#pullrequestreview-363065290

---

From: Mike Bishop <[email-masked]>
Date: Mon, 24 Feb 2020 12:54:27 -0800

@MikeBishop pushed 1 commit.

a41be1873d412fa3026cea0ecd9b5cdc99c4bf33  Review feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3474/files/22bbf32de27e1d3adfc32fd308bf42454a592773..a41be1873d412fa3026cea0ecd9b5cdc99c4bf33

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Feb 2020 13:18:23 -0800

martinthomson approved this pull 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/pull/3474#pullrequestreview-363707201

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Feb 2020 13:19:56 -0800

Marking this as design to avoid accidental closure of the linked issue (which is design).  Including this change in changelogs won't hurt either, though it is extremely minor.

-- 
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/pull/3474#issuecomment-590553857

---

From: ianswett <[email-masked]>
Date: Mon, 24 Feb 2020 13:23:31 -0800

ianswett approved this pull 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/pull/3474#pullrequestreview-363710373