Should we require explicit Abandon after path time-out?

[huitema]

In the proposed text, the server "MAY release the resources associated with a path for which no non-probing packet was received for a sufficiently long path-idle delay." That's fine, but it creates the possibility that the client still considers the path open, resumes sending data on it, and maybe triggers a "stateless reset". That's not so good. I think that we need a couple of addition in the spec:

1) recommend sending a PATH_ABANDON if the server wants to abandon a path for lack of activity. This will avoid the ambiguity about the state of the path.

2) specify how to handle stateless resets on one path when there are other paths that are active.

[mirjak]

This is already in the draft but in section 4.3.1. Use PATH_ABANDON Frame to Close a Path:

PATH_ABANDON frames can be sent on any path, not only the path that is intended to be closed. Thus, a path can be abandoned even if connectivity on that path is already broken. Respectively, if there is still an active path, it is RECOMMENDED to send a PATH_ABANDON frame after an idle time on another path.¶

I did consider moving it to section 4.3.5. Idle Timeout but wasn't sure at the end. However, PR #363 move the "Idle Timeout" section right after the "PATH_ABANDON" section back where it belongs.

[mirjak]

However, I guess the question is should this be rather a MUST then a SHOULD because as long as there is one active path, which has to be the case because otherwise it would be connection close, then there is no reason to not send a PATH_ABANDON frame. the only problem is that there is no way to force the other peer to send a PATH_ABANDON, other than closing the whole connection...

[Yanmei-Liu]

I'd recommend that there's a MUST for each paths' idle timeout:

1. Endpoints MUST send Path Abandon for paths idle timeout. Although endpoints may have different idle timeout threshold, but the Path Abandon frame would always be a clear signal about path closure without ambiguity.

2. In the current draft, there’s a limit to close the last available path(which would cause the whole connection to be closed as described in Section 4.3.1):

If a PATH_ABANDON frame is received for the only active path of a QUIC connection, the receiving peer SHOULD send a CONNECTION_CLOSE frame and enter the closing state. If the client 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.

[mirjak]

@Yanmei-Liu there is already a SHOULD in the text as I cited above. What do you propose to change?

[Yanmei-Liu]

I submit PR #373 for solving this issue as it seems we have consensus on the intern meeting.