[quicwg/base-drafts] Restore CID sequence numbers (#1465)

[Mike Bishop <[e-mail]>]

After trying to find a better way to manage CID changes, probing, etc. I concluded that what we had before and removed is a superior place to start than anything else I'm coming up with.

The result of this PR is that, while we no longer have packet number gaps (so #1280 is no longer an issue), the sequence of CIDs issued by each endpoint is once again ordered.  On each path (local address), you know the sequence number of the CID you're currently using, and you can recognize the sequence number of the CID you're currently receiving (because you assigned it).

Fixes #1452 by requiring that each CID change on a path move to a CID with a greater sequence number; you move to the CID with the matching sequence number if it's usable, but if it's not, you move to something with a higher sequence number.  That will force your peer to meet you on that sequence number instead, and either way you land in equilibrium on each path.

This improves, but doesn't totally fix, the two problems discussed on #1464:
- You can forget the old CIDs you're allowed to use at any time that's convenient to you -- you just won't use them.  Because the CID sequence must advance per path, you can forget old CIDs you've issued once every path has either moved past that sequence number or been abandoned.  However, there's a slight possibility that peers will have different concepts of abandoned (particularly for probing on backup paths that are never migrated to), so we might need to mint a `RETIRE_CONNECTION_IDS` frame to tell the receiver that connection IDs with a sequence before X are no longer recognized by the sender.
- Once you've moved to the CID with sequence number X, the peer knows you can't use CID X-1 on this path even if you've never used it; if you're on the last / next-to-last CID the peer issued, you need more, even if you have some old ones you could still use on a different path.  However, if you have the bad luck to use your last CID for a probe which gets dropped and you're no longer able to send on that path, you can still get stuck if your peer is only giving you one CID at a time.  This probably still requires a `REQUEST_CONNECTION_ID` frame.

While I think the design is mostly sound, this is too wordy.  I'd appreciate help making this more readable.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Revert "Remove sequence number from NEW_CONNECTION_ID"
  * Require CID sequence number ratcheting
  * Prefer equality

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1465.patch
https://github.com/quicwg/base-drafts/pull/1465.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/1465