quicwg / multipath

In-progress version of draft-ietf-quic-multipath
Other
49 stars 18 forks source link

PATH_ABANDON and the sender releasing resources #232

Closed kazuho closed 1 year ago

kazuho commented 1 year ago

Section 4.3 states:

The sender and receiver of a PATH_ABANDON frame should not release its resources immediately, but SHOULD wait for at least three times the current Probe Timeout (PTO) interval as defined in Section 6.2. of [QUIC-RECOVERY] after the last sent packet before sending the RETIRE_CONNECTION_ID frame for the corresponding CID. This is inline with the requirement of Section 10.2 of [QUIC-TRANSPORT] to ensure that paths close cleanly and that delayed or reordered packets are properly discarded. The effect of receiving a RETIRE_CONNECTION_ID frame is specified in the next section.

For the sender of the PATH_ABANDON frame, the only information that it can discard is the ACK queue, because PATH_ABANDON asks the peer to stop sending data on that path. However, the peer is still allowed to send probing packets on the path and therefore we need to retain the ack queue so that we can ACK the probing packets. To summarize, there is nothing that the sender of the PATH_ABANDON frame can discard until it receives RETIRE_CONNECTION_ID.

FWIW, for the receiver of the PATH_ABANDON frame which is the sender of information, it does makes sense to retain loss recovery state as some packets may arrive as late as 3 PTO (that's the rational for 3 PTO in RFC 9000).

kazuho commented 1 year ago

Trying to internalize what the paragraph tries to state, I think my questions are:

These are questions to the transport state machinery that have to be clarified, as they have effect on what the peer can expect.

I think it would be better to have these questions directly answered in the specification rather than talking about "resources" and expecting readers to imply what it means.

kazuho commented 1 year ago

Filed #234 to clarify the questions above, based on my understanding that:

  • At which point MAY an endpoint stop recognizing late-acks for packets sent on the path being abandoned?

This moment is PATH_ABANDON + 3PTO.

  • At which point MAY an endpoint stop decrypting and acking packets arriving on the abandoned path?

This moment is not PATH_ABANDON + 3PTO but is the receipt of RETIRE_CONNECTION_ID, we talk about that in section 4.3.3.

mirjak commented 1 year ago

Please see my comment in the PR about your first question.

mirjak commented 1 year ago

Note that there is also issue #175 which requests clarification for this sentence and another sentence talking about resources in section 4.3.3