search

quicwg / multipath

In-progress version of draft-ietf-quic-multipath
Other
48 stars 17 forks source link

Clarify path id retirement #365

Closed mirjak closed 1 month ago

mirjak commented 1 month ago

I realised that this needs more discussion. However, the problem is the draft in its current form is not consistent. It was always the case that you have to send path_abandon, then wait for 3 PTOs and then send retire_cid. Actually this procedure has had quite some discussion in the past. We can discuss and change that again as things are different now with the path ID. However, I think we should fix the draft now (with this PR) to keep that procedure and then have a separate discussion to change it. Actually there is still issue #295 open which proposed a separate PATH_ID_RETIRE frame.

mirjak commented 1 month ago

To be more concrete here: This is what section 4.3.1. Use PATH_ABANDON Frame to Close a Path says in the currently submitted version of the draft and this PR does not change it but aligns the other pieces with it:

When a path is abandoned, all connection IDs allocated by both of the endpoints for the specified Path ID need to be retired. When sending or receiving a PATH_ABANDON frame, endpoints SHOULD wait for at least three times the current Probe Timeout (PTO) interval after the last packet was sent on the path, as defined in Section 6.2 of [QUIC-RECOVERY], before sending MP_RETIRE_CONNECTION_ID frames. This is inline with the requirement of Section 10.2 of [QUIC-TRANSPORT]. Both endpoints SHOULD send MP_RETIRE_CONNECTION_ID frames for all connection IDs associated to the Path ID of the abandoned path to ensure that paths close cleanly and that delayed or reordered packets are properly discarded.

huitema commented 1 month ago

OK. I will add comments on #295, and we can have a discussion in the interim meeting.