Closed kazuho closed 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.
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.
Please see my comment in the PR about your first question.
Note that there is also issue #175 which requests clarification for this sentence and another sentence talking about resources in section 4.3.3
Section 4.3 states:
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).