Subject: [quicwg/base-drafts] Require peers to check if RETIRE_CONNECTION_ID sequence number is valid (#3037)

From: ianswett <[email-masked]>
Date: Mon, 16 Sep 2019 10:13:43 -0700

An issue to match with PR #3036 

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

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 16 Sep 2019 16:35:28 -0700

Just pasting in the PR text:
> When it comes to error checks for protocol violations, our principle is that easy to implement error checks are REQUIRED. Only error checks that might require a lot of state to perform are optional.
>
>The check that the sequence number retired in a RETIRE_CONNECTION_ID frame is smaller than the highest issued connection ID is a single trivial uint64 comparison. Furthermore, every implementation needs to track the highest issued sequence number anyway, since connection IDs are issued in order.

-- 
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/3037#issuecomment-531997840

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 16 Sep 2019 16:36:36 -0700

I agree with the reasoning here and agree that it’s easy enough to check, but didn’t we consider this previously and decide against it for some reason (reordering or some other issue making this possible to have happen?)?

-- 
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/3037#issuecomment-531998075

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Sep 2019 17:22:38 -0700

Reordering won't change what the maximum sequence number is.  That should be tracked.

-- 
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/3037#issuecomment-532007471

---

From: ianswett <[email-masked]>
Date: Mon, 16 Sep 2019 18:15:49 -0700

I agree with Martin(and Marten).  This is similar to the rule that a peer can't ACK a packet number you've never sent.

-- 
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/3037#issuecomment-532017311

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 16 Sep 2019 18:17:54 -0700

@erickinnear : I have a vague recollection, but I think that might have been about tracking this at the receiver of NEW_CONNECTION_ID frames. This issue is about what the corresponding sender does when the receiver indicates a CID that the sender never sent.

-- 
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/3037#issuecomment-532017665

---

From: MikkelFJ <[email-masked]>
Date: Mon, 16 Sep 2019 22:41:45 -0700

I think there might be issues with checking for _any_ invalid sequence number, but the maximum should be easy. But if that is the case, what is the point of specifically checking for max and not a host of other bad cases? Sanity check...

-- 
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/3037#issuecomment-532067681

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Sep 2019 02:01:23 -0700

I think the question is if we consider *processing* of NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames as a mandatory feature.

Migration is an optional feature of QUIC. For endpoints that do not migrate, there is no reason to update the Connection IDs (note that even though we recently introduced Retire Prior To field, we do not mandate endpoints to respect it - the keyword is "SHOULD"). If we consider that way, I think it is reasonable to never use a MUST for anything related to NEW_CONNECTION_ID or RETIRE_CONNECTION_ID frames.

-- 
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/3037#issuecomment-532130383

---

From: ianswett <[email-masked]>
Date: Tue, 17 Sep 2019 03:53:44 -0700

@kazuho I wouldn't encourage people to think of NEW_CONNECTION_ID and RETIRE_CONNECTION_ID as optional, but I agree that effectively they are in many cases.  However, if you sent NEW_CONNECTION_ID, I don't think it's optional to not correctly process RETIRE_CONNECTION_ID, and that's the question here(I copy-pasted the paragraph above).

If the peer never sends RETIRE_CONNECTION_ID because it doesn't fully implement connection ID functionality, then this is not a problem.

-- 
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/3037#issuecomment-532169215

---

From: Nick Banks <[email-masked]>
Date: Tue, 17 Sep 2019 06:25:12 -0700

I agree with Ian. Processing these frames, and acting accordingly is not optional. Even in the absence of migration RETIRE_CONNECTION_ID can be used to force a peer to start using new connection IDs. WinQuic will make use of this to dynamically balance load of connections across processors; independent of migration.

-- 
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/3037#issuecomment-532219256

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Sep 2019 07:40:18 -0700

@ianswett 
> However, if you sent NEW_CONNECTION_ID, I don't think it's optional to not correctly process RETIRE_CONNECTION_ID, and that's the question here(I copy-pasted the paragraph above).

Thank you for clarifying your position. I'd be perfectly fine if the intent of the proposed change is to  require validation _if the endpoint has sent a NEW_CONNECTION_ID frame_. My problem has been that I have been uncertain if the proposed change meant that; I'd be happy to proposed editorial tweaks to better clarify that.

@nibanks By saying "force a peer to start using new connection IDs", I think you are referring to the Retire Prior To field of the NEW_CONNECTION_ID frame. That's a SHOULD (as the text currently says), IIRC we have agreed on that.

-- 
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/3037#issuecomment-532251562

---

From: ianswett <[email-masked]>
Date: Tue, 17 Sep 2019 07:44:03 -0700

If you've never sent a NEW_CONNECTION_ID, how could receiving a RETIRE_CONNECTION_ID frame ever be valid?

-- 
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/3037#issuecomment-532253120

---

From: Nick Banks <[email-masked]>
Date: Tue, 17 Sep 2019 07:52:06 -0700

@kazuho sorry. You're right, I mean the NEW_CONNECTION_ID frame's Retire Prior To field. But I disagree on your interpretation of the `SHOULD`:
> 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.

The `SHOULD` is for `in a timely manner`. If you don't do it, the connection **will** eventually break, likely via a stateless reset.

-- 
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/3037#issuecomment-532256732

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Sep 2019 07:54:56 -0700

@ianswett The preferred_address TP. An endpoint is allowed, even though not required, to send a RETIRE_CONNECTION_ID frame to retire a CID used during handshake. Quoting from [section 19.16](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.19.16): _An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to indicate that it will no longer use a connection ID that was issued by its peer. This may include the connection ID provided during the handshake._

-- 
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/3037#issuecomment-532258112

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 17 Sep 2019 08:56:11 -0700

@nibanks 
> The `SHOULD` is for `in a timely manner`. If you don't do it, the connection will eventually break, likely via a stateless reset.

The question is the intent of using "SHOULD in a timely manner" rather than "MUST in a timely manner". Yes, the connection would break, if the receiver does not migrate to a new connection ID. However, because we use a SHOULD, that is one of the expected outcomes when an endpoint sends a NEW_CONNECTION_ID frame carrying non-zero Retire Prior To field.

-- 
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/3037#issuecomment-532284657

---

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

@kazuho it sounds like you're arguing that it's an acceptable trade off for clients that don't want to implement support for the Retire Prior To field. I hope that isn't what you're saying. As it is, I'm thinking I'm going to have to add some greasing for this feature to WinQuic.

-- 
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/3037#issuecomment-532291883

---

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

@nibanks
> it sounds like you're arguing that it's an acceptable trade off for clients that don't want to implement support for the Retire Prior To field. I hope that isn't what you're saying.

I am saying that that is the natural way of reading the text. It seems to me that there is a disagreement on what the text implies, and I think it'd be more productive to try to polish up the intent of the text before resorting to encouraging particular behavior through greasing; hence #3046.

-- 
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/3037#issuecomment-532295521

---

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

Thanks @janaiyengar, that sounds about right, this is the other direction, makes sense. 👍

-- 
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/3037#issuecomment-532397251