Home | History | Annotate | Line # | Download | only in quic-design 
      1 QUIC Route Requirements
      2 =======================
      3 
      4 * Two connection IDs -- one local, one remote
      5 
      6 MVP
      7 ---
      8 
      9 MVP does most of one side of the CID management.  The major outstanding items
     10 for 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 
     16 Non zero Length Connection ID
     17 -----------------------------
     18 
     19 MVP does not issue multiple connection CIDs, instead it uses a zero length CID.
     20 To 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 
     29 Connection 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 
     36 Retiring Connection ID
     37 ----------------------
     38 
     39 When 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 
     48 When 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 
     54 When 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 
     61 State
     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