1QUIC Route Requirements
2=======================
3
4* Two connection IDs -- one local, one remote
5
6MVP
7---
8
9MVP does most of one side of the CID management.  The major outstanding items
10for a complete implementation are:
11
12* possibly increase the number of CIDs we permit (from 2)
13* use more than the just latest CID for packet transmission
14  * round robin non-retired CIDs
15
16Non zero Length Connection ID
17-----------------------------
18
19MVP does not issue multiple connection CIDs, instead it uses a zero length CID.
20To achieve this, more work is required:
21
22* creation of new CIDs (coded but not used)
23* responding to new CIDs by returning new CIDs to peer match
24* managing the number of CIDs presented to our peer
25* limiting the number of CIDs issued & retired
26* retirement of CIDs that are no longer being used
27* ensuring only one retire connection ID frame is in flight
28
29Connection Migration
30--------------------
31
32* Supporting migration goes well beyond CID management.  The additions required
33  to the CID code should be undertaken when/if connection migration is
34  supported.  I.e. do this later in a just in time manner.
35
36Retiring Connection ID
37----------------------
38
39When a remote asks to retire a connection ID (RETIRE_CONNECTION_ID) we have to:
40
41* Send retirement acks for all retired CIDs
42* Immediately delete all CIDs and routes associated with these CIDs
43  * Retransmits use different route, so they are good.
44  * Out of order delivery will initiate retransmits
45* Should respond with a NEW_CONNECTION_ID frame if we are low on CIDs
46  * Not sure if it is mandatory to send a retirement.
47
48When a remote creates a new connection ID:
49
50* May respond with a new connection ID frame (it's a good idea)
51* It reads like the NEW_CONNECTION_ID frame can't be used to retire routes.
52  However, see above.  Suggest we accept either.
53
54When we want to retire one (or more) connection IDs we have to:
55
56* Flag the route(s) as retired
57* Send a retirement frame (RETIRE_CONNECTION_ID)
58* Delete the connection(s) once they are retired by our peer (either
59  NEW_CONNECTION_ID or RETIRE_CONNECTION_ID can do this)
60
61State
62-----
63
64* routes we've retired until they are acked as being retired (uint64_t max CID)
65* routes our peer has retired don't need tracking, we can remove immediately
66* retired routes where we've outstanding data to send will have that data
67  sent before the retirement acks are send.  If these fragments need to
68  be retransmitted, they'll be done so using a new CID on a new route.
69  This means, there is no requirement to wait for data to be flushed
70  before sending the retirement ack.
71