Draft: draft-ietf-quic-transport

Commentary: Removes guidance on specific times in favor of descriptions of what the CID issuer might have to do if it can no longer support outstanding CIDs . I believe the impact of this is editorial , but I touched normative statements , so if anyone disagrees please scream . 
 Marking this as design to avoid accidental closure of the linked issue ( which is design ) . Including this change in changelogs wo n't hurt either , though it is extremely minor . 
 there are a couple of outstanding comments -- can you handle those and close this off ? 
 Requiring RETIRECONNECTIONID has lead to all sorts of corner cases . For instance , a server can force a client to retire the connection ID that is still in use for the handshake . ( We 're uncertain yet as to whether the newly provided connection ID usable here , so this only might cause genuine problems . ) More to the point , this design assumes things about the nature of connection IDs and routing infrastructure that imply a coupling between path and endpoint state . The reason you might want to retire a connection ID forcibly in this fashion is that it is no longer usable for routing purposes ( or that it results in suboptimal routing , perhaps where packets need to be bounced between nodes in a cluster ) . All of this implies that the address tuple is part of the routing assessment . That makes this feature fragile and it also creates some uncertainty about whether it is possible to build such a system without having a stateless reset oracle . 
 Just to clarify , my understanding of the problem here is n't itself , but rather that an issuer of a CID can send to require that the consumer MUST retire the CID immediately ? 
 I 'm not sure if I follow what you state here . Much like a TLS server having a master key that encrypts TLS session tickets , a server might have a master key that is used for encrypting all the CIDs , and it rotates that key periodically . In such a design ( which I 'd assume to be pretty normal ) , there is nothing related to paths . 
 MsQuic also uses CIDs and RetirePriorTo to encode " on machine " routing information , such as per - CPU partitioning . When we rebalance load across these partitions , we generate new CIDs to match . I also do n't quite understand the point of this issue . If the problem is just that we do n't want CIDs to change before a certain time , I 'm fine with adding some extra restrictions on that . But I 'm very strongly against removing this feature ( assuming that 's the goal of this issue ) . 
 This is n't about being bound to addresses , though . It 's about anything in the server infrastructure changing . That could be rotation of the keys used to encrypt a structure to produce packet IDs . I think there 's a separate discussion about whether CIDs can be bound to server IPs for preferred addresses , but that 's covered by already . 
 Discussed in ZRH . Proposed resolution is to prepare a PR that clarifies the consequences for both sides on what happens when an endpoint sends a NEWCONNECTIONID frame , and for the receiver for what it means if it does n't retire . Also , remove PTO from text related to retirement . 
 Thanks for writing this up !
Paragraph (version B):
An endpoint might need to stop accepting previously issued connection
IDs in certain circumstances.  Such an endpoint can cause its peer to
retire connection IDs by sending a NEW_CONNECTION_ID frame with an
increased Retire Prior To field.  The endpoint SHOULD continue to
accept the previously issued connection IDs until they are retired by
the peer.  If the endpoint can no longer process the indicated
connection IDs, it MAY close the connection.