Subject: [quicwg/base-drafts] Why are we bothering to number CIDs? (#2159)

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 13:02:32 -0800

Each CID comes with a number but as far as I can tell, all its used for
is to (a) check for duplicates and (b) retire the CID. Given the
relatively small number of retirements, it's not clear that this is
a win. Why not just refer to CIDs by value? You are required to check
for duplicate valus anyway in 19.15

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 13 Dec 2018 21:18:23 +0000 (UTC)

I won't claim to be into all the details, but the sequence numbers were removed and reintroduced because of some complex race conditions or so.

> Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number greater than any previously sent to the peer MAY be treated as a connection error of type PROTOCOL_VIOLATION.

The duplicate check is to guard against inconsistent behaviour but are not essential to why there are sequence numbers.

-- 
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/2159#issuecomment-447124005

---

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Dec 2018 14:33:49 -0800

Because you're not realistically going to retain a total history of all CIDs you've ever seen.  You MAY treat it as an error if you notice that one recurs, so that servers are disincented from doing so, but you're not obliged to check that over the whole connection lifetime.  However, without maintaining that history for a sufficiently long time, you then can't differentiate for certain between a retransmission of an old NCID frame and a new issuance of the same CID (an error, but one you might miss).  Therefore, you could wind up in a state where the peers disagree about whether a CID is still live.

The options were a requirement to keep history for a certain length of time (and hope that packets don't get delayed longer than whatever arbitrary timeout we pick) or using sequence numbers and allowing tracking with a similar data structure as that which tracks whether Stream IDs are not-yet-open, open, or closed.

-- 
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/2159#issuecomment-447145188

---

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 22:47:39 +0000 (UTC)

I'm not persuaded by this. There are two cases:

1. An erroneous duplicate NCID.
2. Duplicated packets in the network.

If the other side is broken, there's no guarantee of consistency between
the sides in any case. So, we're only talking about the second case. And I
don't think it's particularly difficult to pick a timeout here, because
we're talking about the race between RETIRE_CONNECTION_ID and the packets
duplicate in the network, so a timeout on the order of 2MSL is basically
fine.

On Thu, Dec 13, 2018 at 2:33 PM Mike Bishop <[email-masked]>
wrote:

> Because you're not realistically going to retain a total history of all
> CIDs you've ever seen. You MAY treat it as an error if you notice that one
> recurs, so that servers are disincented from doing so, but you're not
> obliged to check that over the whole connection lifetime. However, without
> maintaining that history for a sufficiently long time, you then can't
> differentiate for certain between a retransmission of an old NCID frame and
> a new issuance of the same CID (an error, but one you might miss).
> Therefore, you could wind up in a state where the peers disagree about
> whether a CID is still live.
>
> The options were a requirement to keep history for a certain length of
> time (and hope that packets don't get delayed longer than whatever
> arbitrary timeout we pick) or using sequence numbers and allowing tracking
> with a similar data structure as that which tracks whether Stream IDs are
> not-yet-open, open, or closed.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/2159#issuecomment-447145188>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1oceRNi0ITMvVBtKHr-pt0lwaBKKxks5u4tXMgaJpZM4ZSa1C>
> .
>

-- 
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/2159#issuecomment-447149186

---

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Dec 2018 22:56:26 +0000 (UTC)

This goes back to the thing you didn't like about receiving lower-valued MAX_STREAM_DATA frames -- some implementations might have naive retransmission strategies that retransmit frames which don't actually matter anymore.  It's suboptimal, but not illegal.  If the frame shows up, even a really long time later, we've stated that's not a failure condition.

-- 
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/2159#issuecomment-447151452

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Dec 2018 17:57:51 -0800

The bug that this fixes is one where a new connection ID is retired quickly AND there are retransmissions of the NEW_CONNECTION_ID frame that arrive after the retiring happens.  In that case, the NEW_CONNECTION_ID will appear to create a new connection ID, when in practice it is already retired.

We discussed using timers - I argued for that, I think - but this was more provably correct.

-- 
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/2159#issuecomment-447186494

---

From: janaiyengar <[email-masked]>
Date: Fri, 14 Dec 2018 17:40:44 -0800

Right - this fixes the bug where an endpoint retires quickly and forgets and now considers a retransmission to be a brand new CID.  It's easier to ensure correctness with counters, and it's easy enough to implement. I suggest we leave this as is.

-- 
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/2159#issuecomment-447526150