Draft: draft-ietf-quic-transport

Commentary: The text in the PR adopts 1 PTO as a suggestion , as I am not sure if there is a point in that value being the exact limit . If it needs to be , we can rephrase the text to " MUST retire the corresponding connection IDs in one PTO and send corresponding RETIRECONNECTIONID frames . " 
 I 'm a bit worried that a stateless reset from a retired CID could be used as an attack vector by simply delaying packets en - route . However , if the reset is only effective on CIDs that are no longer recognised that should n't be a problem . 
 At the moment , states , quote : Upon receipt , the peer SHOULD retire the corresponding connection IDs and send the corresponding RETIRECONNECTIONID frames in a timely manner . Failing to do so 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 . As the text uses " SHOULD " rather than a " MUST " , some view it as an optional requirement to switch to using a new connection ID in such a situation . Others think that it is a mandatory requirement for an endpoint to switch to a new connection ID . If we are to consider the latter behavior to be the case , I think the text should better be changed to " MUST retire the corresponding connection IDs and send the corresponding RETIRECONNECTIONID frames in a timely manner " . 
 My personal take is that it would be nice if the processing of NEWCONNECTIONID frame and RETIRECONNECTIONID frame can be an optional feature . QUIC is already very complex , and it would be beneficial to have some features being optional , in sense that endpoints can simply discard certain frames when not implementing certain features . IIUC , at the moment , these two frames are optional for an endpoint that do not support migration . OTOH , from the robustness viewpoint of the protocol , it does make sense to change the text to MUST . We might have already crossed the river by introducing the Retire Prior To field . The third option is to add a TP that indicates if an endpoint supports retirement of connection IDs ... 
 There was a lot of discussion when the Retire Prior To feature was . At the time , I felt it pretty clear that it could not be optional from our server 's perspective . I agree the sentence with the SHOULD , if read in isolation , could be interpreted as making the feature as optional . But the sentence immediately following it makes it pretty clear that it 's not option . I understand the desire to make things optional for simplicity 's sake , but a primary point of this feature , when it was , was that is was required . Making it optional now would , IMO , defeat the purpose of the feature . 
 My understanding is that this is optional in the sense GOAWAY is optional . At some point , the connection is likely to terminate abruptly if you do n't follow the request . 
 That 's one way to look at it . The difference here is that we 're not trying to kill the connection with   To . 
 There was definitely lots of discussion around the requirement level here when this was ( see ) , asked : There was good discussion following that ( and scroll down ) . My understanding of was that the endpoint being asked to retire a CID really SHOULD retire it or else the peer may stop responding to that CID . After the endpoint requesting retirement gives up on a CID and forgets about it , packets will either arrive with that CID or they will not . It has two choices , it can choose to process them if they arrive with the wrong CID , or it can drop them . The enforcement mechanism here is to stop processing the " bad " CIDs , not close the connection , especially as you take into account potentially delayed - but - valid packets . I think the current stance of " really SHOULD stop using such a CID , but the other endpoint needs to be careful about enforcing that " is the right one , if there 's a wording update that would help with understanding there , then it would be great to update the wording as an editorial issue . 
 Whatever the answer here , the SHOULD was chosen because " timely manner " is n't defined in a testable fashion . If someone wants to argue for MUST , then we need a firmer definition of the reaction . 
 And to agree with the squishiness here only exists up until the point that this is " do this or else " . We should make it clearer that the cost of non - compliance is losing the connection . Not always , but a endpoint is entitled to cut and run if their peer does n't comply . 
 Thank you for the explanation and the links . They help a lot in understanding how we ended up here . Yeah we already state that " an endpoint MAY discard a connection ID for which retirement has been requested once an interval of no less than 3 PTO has elapsed since an acknowledgement is received for the NEWCONNECTIONID frame requesting that retirement . " So I think it 's testable . Considering that we have a MAY on the side that initiates the retirement , I think we can have a MUST on the receiver side ( assuming that we want to ) . 
 That almost works , except that PTO is n't a shared variable . It 's subjective and so endpoints might disagree on where this line is . At 3PTO , that 's probably not a disagreement worth having , but you are effectively recommending instant compliance if you set the bar that low , as packet loss on any packet sent that attempts to comply might cause it to take up to  to get through . 
 IIRC , the base of the SHOULD was that we did n't have a specific timeout anyone felt comfortable enforcing in the absence of shared timers between peers . We 've had a general principle that requirements you ca n't tell whether the peer violated are probably SHOULDs instead of MUSTs . As  says , the SHOULD is intended to refer to doing so promptly , not to doing so at all . 
 While I agree that we have tried to make MUST requirements testable , I am not certain if it is a good idea to avoid use of MUST when a requirement can not be tested ( or if doing so is a good idea , per the definition of the keywords in RFC 2119 ) . At least for this particular case , is n't it a requirement for an endpoint to drop the old connection IDs ? Though I could well be wrong though in how the keywords are used in practice . 
 I 'm fine saying MUST drop in a timely manner , and being explicit about what we mean by timely manner ( 3 PTO from the peer 's perspective ) . Obviously , from the peer 's perspective , that is enforceable . Locally though , it 's obviously not as clear cut . 
 We need a PR . do you think that you can do this ? As discussed , should be that the receiving side will retire within one PTO . The sending side can enforce at 3PTO , by dropping the connection . 
 Discussed in Cupertino . to quickly rev the PR to incorporate suggestion . 
 the delayed packets are handled by this text : If you 've followed the requirement to retire as indicated , then a delayed packet triggering stateless reset ca n't hurt you . Looks fine to me . I 'm also fine with Martin 's suggestions as well . The endpoint here has always been going to do whatever it does , regardless of whether we said SHOULD or MUST , so this seems fine . I do like the direction for the other endpoint to wait  , that would be nice to include .
Paragraph (version A):
An endpoint can request that its peer retire connection IDs by
sending a NEW_CONNECTION_ID frame with an increased Retire Prior To
field.  Upon receipt, the peer SHOULD retire the corresponding
connection IDs and send the corresponding RETIRE_CONNECTION_ID frames
in a timely manner.  Failing to do so 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.
Paragraph (version A):
An endpoint MAY discard a connection ID for which retirement has been
requested once an interval of no less than 3 PTO has elapsed since an
acknowledgement is received for the NEW_CONNECTION_ID frame
requesting that retirement.  Subsequent incoming packets using that
connection ID could elicit a response with the corresponding
stateless reset token.
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
and send corresponding RETIRE_CONNECTION_ID frames.  Failing 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.
Paragraph (version B):
An endpoint MAY discard a connection ID for which retirement has been
requested once an interval of no less than 3 PTO has elapsed since an
acknowledgement is received for the NEW_CONNECTION_ID frame
requesting that retirement.  Until then, the endpoint SHOULD be
prepared to receive packets that contain the connection ID that it
has requested be retired.  Subsequent incoming packets using that
connection ID could elicit a response with the corresponding
stateless reset token.