Draft: draft-ietf-quic-transport

Commentary: When it comes to error checks for protocol violations , our principle is that easy to implement error checks are REQUIRED . Only error checks that might require a lot of state to perform are optional . The check that the sequence number retired in a RETIRECONNECTIONID frame is smaller than the highest issued connection ID is a single trivial  comparison . Furthermore , every implementation needs to track the highest issued sequence number anyway , since connection IDs are issued in order . 
 This is small and I support it , but I think it needs to be marked design and run through the process because it changes normative language . 
 An issue to match with PR The text is : " Receipt of a RETIRECONNECTIONID frame containing a sequence number greater than any previously sent to the peer MAY(-MUST ) be treated as a connection error of type PROTOCOL_VIOLATION . " 
 Just pasting in the PR text : 
 I agree with the reasoning here and agree that it ’s easy enough to check , but did n’t we consider this previously and decide against it for some reason ( reordering or some other issue making this possible to have happen ? ) ? 
 Reordering wo n't change what the maximum sequence number is . That should be tracked . 
 I agree with Martin(and Marten ) . This is similar to the rule that a peer ca n't ACK a packet number you 've never sent . 
 : I have a vague recollection , but I think that might have been about tracking this at the receiver of NEWCONNECTIONID frames . This issue is about what the corresponding sender does when the receiver indicates a CID that the sender never sent . 
 I think there might be issues with checking for any invalid sequence number , but the maximum should be easy . But if that is the case , what is the point of specifically checking for  and not a host of other bad cases ? Sanity check ... 
 I think the question is if we consider processing of NEWCONNECTIONID and RETIRECONNECTIONID frames as a mandatory feature .  is an optional feature of QUIC . For endpoints that do not migrate , there is no reason to update the Connection IDs ( note that even though we recently introduced   To field , we do not mandate endpoints to respect it - the keyword is " SHOULD " ) . If we consider that way , I think it is reasonable to never use a MUST for anything related to NEWCONNECTIONID or RETIRECONNECTIONID frames ( except for parsing and skipping them ) . 
 I would n't encourage people to think of NEWCONNECTIONID and RETIRECONNECTIONID as optional , but I agree that effectively they are in many cases . However , if you sent NEWCONNECTIONID , I do n't think it 's optional to not correctly process RETIRECONNECTIONID , and that 's the question here(I copy - pasted the paragraph above ) . If the peer never sends RETIRECONNECTIONID because it does n't fully implement connection ID functionality , then this is not a problem . 
 I agree with  . Processing these frames , and acting accordingly is not optional . Even in the absence of migration RETIRECONNECTIONID can be used to force a peer to start using new connection IDs . WinQuic will make use of this to dynamically balance load of connections across processors ; independent of migration . 
 Thank you for clarifying your position . I 'd be perfectly fine if the intent of the proposed change is to require validation if the endpoint has sent a NEWCONNECTIONID frame . My problem has been that I have been uncertain if the proposed change meant that ; I 'd be happy to proposed editorial tweaks to better clarify that . By saying " force a peer to start using new connection IDs " , I think you are referring to the Retire Prior To field of the NEWCONNECTIONID frame . That 's a SHOULD ( as the text currently says ) , IIRC we have agreed on that . 
 If you 've never sent a NEWCONNECTIONID , how could receiving a RETIRECONNECTIONID frame ever be valid ? 
 sorry . You 're right , I meant the NEWCONNECTIONID frame 's Retire Prior To field . But I disagree on your interpretation of the : The is for . If you do n't do it , the connection will eventually break , likely via a stateless reset . 
 The preferredaddress TP . An endpoint is allowed , even though not required , to send a RETIRECONNECTIONID frame to retire a CID used during handshake . Quoting from : An endpoint sends a RETIRECONNECTIONID frame ( type=0x19 ) to indicate that it will no longer use a connection ID that was issued by its peer . This may include the connection ID provided during the handshake . _ 
 The question is the intent of using " SHOULD in a timely manner " rather than " MUST in a timely manner " . Yes , the connection would break , if the receiver does not migrate to a new connection ID . However , because we use a SHOULD , that is one of the expected outcomes when an endpoint sends a NEWCONNECTIONID frame carrying non - zero Retire Prior To field . 
 it sounds like you 're arguing that it 's an acceptable trade off for clients that do n't want to implement support for the Retire Prior To field . I hope that is n't what you 're saying . As it is , I 'm thinking I 'm going to have to add some greasing for this feature to WinQuic . 
 I am saying that that is the natural way of reading the text . It seems to me that there is a disagreement on what the text implies , and I think it 'd be more productive to try to polish up the intent of the text before resorting to encouraging particular behavior through greasing ; hence . 
 Thanks that sounds about right , this is the other direction , makes sense .
Paragraph (version A):
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.
Paragraph (version B):
Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number
greater than any previously sent to the peer MUST be treated as a
connection error of type PROTOCOL_VIOLATION.