Clarifications on PATH_ABANDON #46
Conversation
fixes #32 Please carefully review the text about abandon frames on the last active path. This is new and maybe not what you intended, however, because of potential crossing of abandon frames from each direction (as mentioned by @huitema in the issue), I don't think receiving an abandon frame on the last active path should be a protocol violation.
mirjak
requested review from
huitema,
Yanmei-Liu,
obonaventure and
qdeconinck
as code owners
| received a PATH_ABANDON frame for the last open path, it MAY instead try to open a new path, if | ||
| available, and only initiate connection closure if path validation fails or a CONNECTION_CLOSE frame | ||
| is received from the server. Similarly the server MAY wait for a short, limited time such as one RTO | ||
| if a path probing packet is received on a new path before sending the CONNECTION_CLOSE frame. |
There was a problem hiding this comment.
Would it be more clear that the endpoint just use CONNECTION_CLOSE frame immediately if the endpoint don't want to use the last path?
There was a problem hiding this comment.
Yes, that's what the client/sender should do. However this text is discussing what happens if you received a PATH_ABANDON on the last open path despite.
We could consider this as a protocol violation, however, as two PATH_ABANDON frames for each end could cross each other if both ends are allow to send PATH_ABANDON, I don't think it should be a protocol violation.
We could add one more sentence that usually CONNECTION_CLOSE should be used to close the last open path.
|
|
||
| Packets, that have previously been send on the abandoned path and are considered lost, SHOULD be | ||
| retransmitted on a different path. | ||
|
|
There was a problem hiding this comment.
| If an endpoint wants to close the last open path of a connection, it MUST use the CONNECTION_CLOSE frame as specified in {{RFC9000}}. | |
draft-lmbdhk-quic-multipath.md
Outdated
| as "abandoned", it means that the resources related to the path can be released. | ||
| as "abandoned", it means that the resources related to the path, such as the used connection IDs, can be released. | ||
| However, information related to data delivered over that path SHOULD not be released immediately | ||
| as ACK can still be received on other frame that also may trigger retransmission of data on another path. |
There was a problem hiding this comment.
"as acknowledgment can still be received or other frame that..."
draft-lmbdhk-quic-multipath.md
Outdated
| as ACK can still be received on other frame that also may trigger retransmission of data on another path. | ||
|
|
||
| The endpoint sending the PATH_ABANDON frame SHOULD consider a path as abandoned when the ACK for the | ||
| packet that contained the PATH_ABANDON frame was received. When releasing resources of a path, |
There was a problem hiding this comment.
"when the packet that contained the PATH_ABANDON frame got acknowledged"
draft-lmbdhk-quic-multipath.md
Outdated
| might need to rely on an idle time out to close the path, as described in Section {{idle-time-close}}. | ||
|
|
||
| Packets, that have previously been send on the abandoned path and are considered lost, SHOULD be | ||
| retransmitted on a different path. |
There was a problem hiding this comment.
I would precise that the retransmittable frames (or content) of these packets should be retransmitted
I believe the intention was to add this sentence as part of PR #46 so I'm committing directly to master.
fixes #32
Please carefully review the text about abandon frames on the last active path. This is new and maybe not what you intended, however, because of potential crossing of abandon frames from each direction (as mentioned by @huitema in the issue), I don't think receiving an abandon frame on the last active path should be a protocol violation.