Path abandonment is underspecified

[michael-eriksson]

The exact sequence of events during path abandonment is underspecified (or maybe underexemplified) in the document. It is, however, specifed that:

After sending the PATH_ABANDON frame, the endpoint MUST NOT send frames that use the Path ID anymore, even on other network paths.

This requirement is a little hard to parse, but if read literally it would mean that incoming packets could not be acknowledged after a PATH_ABANDON frame has been sent. This would imply that a whole RTT-flight of packets in the other direction would be unacknowledged and thus needlessly retransmitted.

This is the way I think that endpoint A abandoning a path with endpoint B should be done:

1. A stops sending new ack-eliciting packets on the path and waits for all packets in flight to be acknowledged or the tail loss probe timer to expire.
2. A sends a PATH_ABANDON frame to B. After that, A continues to acknowledge incoming packets from B, on the same or another path.
3. B receives and acknowledges the packet with the PATH_ABANDON frame. It does not immediately send a reciprocal PATH_ABANDON frame, but first waits for acknowledgments of the packets it has in flight (just like A did before it sent its PATH_ABANDON).
4. When all of B's packets in flight have been acknowledged, or the tail loss probe timer has expired, it send the PATH_ABANDON to A and removes all state is has for the path.
5. When A receives the PATH_ABANDON from B, it removes all state is has for the path and the path is completely abandoned.

This procedure also handles concurrent abandonment from both endpoints well.

[mirjak]

Yes we need to correct the sentence to exclude PATH_ACKs. This was an oversight. I created PR #456.

However, the procedure described above is not correct and not what is specified in the draft. B has to sent the PATH_ABANDON immediately and then both endpoints wait for 3PTO after receiving the PATH_ABANDON before they remove state. As usually all packets sent before the PATH_ABANDON will receive before the PATH_ABANDON and therefore will be ACKed, there is no need to wait for the ACKs first. If there is re-ordering, that's why we have the 3 PTO waiting time. Also note that when you try to wait for the ACKs first, you also need a 3 PTO timer as they might never arrive. Therefore I don't think it's really useful to wait for the ACKs first.

[huitema]

There is no oversight. The handling of acknowledgements is fully specified in:

3.3.2. Handling PATH_ACK for abandoned paths

When an endpoint decides to send a PATH_ABANDON frame, there may still be some unacknowledged packets. Some other packets may well be in transit, and could be received shortly after sending the PATH_ABANDON frame. As specified above, the endpoints SHOULD send PATH_ACK frames promptly, to avoid unnecessary data retransmission after the peer deletes path resources.
These PATH_ACK frames MUST be sent on a different path than the path being abandoned.PATH_ACK frames received after the endpoint has entirely deleted a path MUST be silently discarded.

The problem is in the sentence added at the end of section 7.2. PATH_ABANDON Frame. The text contradicts the more specification text in the "path close" section. That text should be replaced by a reference to path close.

[michael-eriksson]

Hmm, I wanted to initiate a discussion about the best way to do and specify path abandonment, by describing an efficient and clear procedure above. Let me be point more explicitly on some issues, using the same A (initiator) and B roles as in the example above:

B's sending of PATH_ABANDON

Section 3.3 (Path Close) says:

When an endpoint receives a PATH_ABANDON frame, it MUST send a corresponding PATH_ABANDON frame if it has not already done so.

It does not say when this has to be done, and in particular what B is allowed to do before it sends the PATH_ABANDON frame. I argue above that B should wait until it has no packets in flight. When A then receives the PATH_ABANDON, it can directly delete all state for the path instead of waiting for 3PTO.

Forcing B to immediately send a PATH_ABANDON frame is pointless, it adds not information since A will anyway get an acknowledgment that the PATH_ABANDON frame it sent has been received.

Sending in-path acknowledgments after having sent PATH_ABANDON

Section 3.3 (Path Close) says:

The current draft does not allow sending acknowledgments for incoming packets on the same path after a PATH_ABANDON frame has been sent.

Why is this? Acknowledgements are often sent on same path, and there is no reason to not allow that when the path is closing down.

The draft supports break-before-make path changes, e.g.:

If the client received a PATH_ABANDON frame for the last open path, it MAY instead try to open a new path [...]

The only place to acknowledge the packets in flight would be on the same, last, path.