Draft: draft-ietf-quic-transport

Commentary: It might be cleaner to say that when you receive  , you need to retire the indicated sequence numbers even if you have n't received them yet . Then you can just discard the NCID frames upon arrival . 
 That brings with it a request to replace them , which could get a little messy if I sent  of , it seems like it would cut down on useless traffic if we did n't generate the RCID frames until someone actually tries to use them ? 
 The situation is a bit perverse to begin with . RPT is n't permitted to be = the sequence number of the new CID , which means they 've already issued you 10k CIDs for that situation to be real . If the peer revokes a block of 10k CIDs via RPT , they 're expecting to get 10k RCID frames , minus any that might already have been sent . Yes , that means they might then issue a similarly large block of CIDs , which you will then forget silently and the insanity will play itself out again the next time they revoke a large batch . This glut is best managed by using the existing TP and not permitting the peer to send you an unlimited number of CIDs . This also argues , perhaps , for making the default something more sensible than " infinite " in . 
 There 's a DoS attack here . If the attacker does n't comply with the rule that new CIDs have to be issued in order ( which is one of the non - enforceable MUSTs in the spec ) and issues you CID while with the same value for   To , the endpoint would have to send a million RETIRECONNECTIONID frames . I think the only way to reliable avoid this DoS is to only send RETIRECONNECTIONID for CIDs that you actually received . 
 Larger change , but one solution to that might be permitting a RCID frame to retire ranges instead of a single CID . 
 what about RETIRECONNECTIONID meaning that all IDs equal or less than that one have been retired ? That would force them to be used in order , which seems like a feature in my opinion . 
 We had that at one point , did n't we ? It is a feature until you start doing probes on other paths . If you use a CID on a different path , then want to retire it , that also retires a CID you might still be using on the main path . And it 's no problem if you have another CID to roll forward to , but it forces you to burn more CIDs than you otherwise would . I believe there was also an objection to that model that the gratuitous CID rolls leaked signals about use of other paths . 
 So I think if we were to do that , it would have to be a flag that indicates whether it 's a point retirement or an " everything up to " retirement . That would require renumbering some frames , which would be a pain . 
 I 'm not sure if there 's a problem here that we need to solve . The DoS that I described only works if an endpoint sends RETIRECONNECTIONID frames for CIDs that it has n't received / does n't remember any more . As long as you only retire CIDs that you 're actually keeping track of ( as the spec currently says ) , the DoS does n't work . 
 The implication , of course , is that 0 = infinite , but we do n't actually say that anywhere . ( This part might be editorial ; it omits to say what we all know it means . ) 1 is also a mostly - invalid value , since you ca n't avoid exceeding that limit without the peer dropping to zero CIDs in the interim and therefore stalling the connection for an RTT + any recovery time needed . Also , if the server uses , it has provided two CIDs before it knows the client 's limit . This is fine , really , so long as the peer SHOULD NOT exceed the limit ; if you send ( or default to ) a stupid value , the peer will ignore you and all is well . But if we take 's suggestion that exceeding the limit be a MUST NOT , the default needs to be infinite and values less than 2 need to be prohibited . 
 ( Design issue please . ) There is a lower point on the idle_timeout , which is . Having 0 imply is awkward , so I think that  's suggestion is the best outcome . 
 I am literally not sure if this is the case . As I 've pointed out in , the normative language suggests that activeconnectionidlimit actually means the number of " spare " CIDs that should be available , though the definition of " active connection ID " is defined differently . If we are to consider the normative language as being correct , it would be totally valid to set activeconnectionidlimit to 1 ( i.e. I want one spare CID ! ) , or 0 ( i.e. I do not want any ) . 
 The definition of the transport parameter says : So sending a value of 0 ( or , as it currently stands , omitting the TP ) , is a valid thing to do . It 's an endpoint declaring that it will never , under no circumstances , change the connection ID , but to keep on using the connection ID provided during the handshake . Of course this also implies that connection migration is effectively disabled . We might want to decide to make this illegal though . Since the introduction of the Retire Prior To field on the NEWCONNECTIONID frame , implementations have the option to retire connection IDs in case their infrastructure requires that . A peer sending a value of 0 would prevent those implementations from rotating their connection ID mapping , which seems like an awkward special case . As points out , sending a value of 1 does n't make any sense , since you ca n't switch to a new CID without stalling the connection first . Therefore , I agree with suggestion to forbid values below 2 . I 'm undecided if we should define a default value , and if so , what that value should be . 
 Discussed in Singapore ; a bit more discussion and then CfC. 
 Let 's say an endpoint receives a NEWCONNECTIONID frame with Sequence Number : X , Retire Prior To : M. At a later moment , it receives a ( reordered ) NEWCONNECTIONID frame with Sequence Number : N ( where N < M ) . As the spec is currently written , it would be perfectly legal to use CID N at this moment . Obviously , this does n't make sense , since the receiving peer is about to or has already stopped accepting packets with using CIDs < M. When receiving such a reordered NEWCONNECTIONID frame , the reasonable thing to do is to immediately send the corresponding RETIRECONNECTIONID frame for    , I think that was the intent all along , we just missed the text . Thanks for the close read ! 
 Technically design , so we 'll need a consensus call , but the PR is probably the best way to address this . 
 Small editorial suggestion , but  tweak to wording suggestion , but otherwise looks good !
Paragraph (version B):
An endpoint can cause its peer to retire connection IDs by sending a
NEW_CONNECTION_ID frame with an increased Retire Prior To field.
Upon receipt, the peer MUST retire the corresponding connection IDs
using RETIRE_CONNECTION_ID frames.  Failure to retire the connection
IDs within approximately one PTO 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.