What happens when a CID is retired and no new CID is available anymore #171
Conversation
draft-ietf-quic-multipath.md
Outdated
| E.g this can happen if the Connection ID issuer requests retirement of a | ||
| Connection ID using the Retire Prior To field in the NEW_CONNECTION_ID Frame. | ||
| If no new connection ID is available anymore, the endpoint cannot send on | ||
| this path anymore but has to wait for the idle time-out before closing |
There was a problem hiding this comment.
I'm not sure that the endpoint "has to wait" the idle timeout to close the path. I could also send a PATH_ABANDON to explicitly close the path, right? Instead, do we want to state here that an inactivity larger than the idle timeout implies an implicit path closure?
There was a problem hiding this comment.
Currently it can't send an PATH_ABANDON because if we don't have a CID we don't have a valid path ID.
There was a problem hiding this comment.
Oh indeed, I went too quick on this one :-)
There was a problem hiding this comment.
I do mention this issue in #169
There was a problem hiding this comment.
Actually we could say that the endpoint should first send the path abandoned frame and then the retire CID frame. However, those frames probably don't have to be processed in order and we need to address issue #137 properly. Or alternative you have to wait until the path abandoned frame is ack'ed and then send the retire CID frame but that would introduce a delay. Not sure how bad that is.
Co-authored-by: Quentin De Coninck <quentin.deconinck@uclouvain.be>
|
After author discussion: we need to also add a sentence about control frames |
draft-ietf-quic-multipath.md
Outdated
| This can happen if, e.g., the Connection ID issuer requests retirement of a | ||
| Connection ID using the Retire Prior To field in the NEW_CONNECTION_ID frame. | ||
| If no new connection ID is available anymore, the endpoint cannot send on | ||
| this path and is not able to send control frames associated to this path anymore. |
There was a problem hiding this comment.
Given the clarification in #185, Multipath control frames include the DCID sequence number used by their peer. So if an endpoint sends a RETIRE_CONNECTION_ID, it cannot send on that path anymore if it does not have spare CIDs anymore. But when the receiver receives the RETIRE_CONNECTION_ID (which may have issued the NEW_CONNECTION_ID with the increased Retire Prior To beforehand), it cannot send control frames related to that path anymore. I think there is a difference here w.r.t. the current text.
note that there is one more paragraph in this section that I didn't update. That paragraph is still correct but might need some rewording given the new text.
| by its peer over another path, the endpoint can re-activate the path by | ||
| sending a packet with a new Connection ID on that path. | ||
|
|
||
| If the sender retires a Connection ID that is still used by | ||
| in-flight packets, it may receive ACK_MP frames referencing the retired | ||
| Connection ID. If the sender stops tracking sent packets with retired | ||
| Connection ID, these would be spuriously marked as lost. To avoid such |
There was a problem hiding this comment.
This paragraph is still correct but doesn't fit perfectly anymore. I guess we could try to reword now or later...
Co-authored-by: Quentin De Coninck <quentin.deconinck@uclouvain.be>
|
This seems ready to merge. Plan is to merge end of tomorrow (Friday). |
No description provided.