Abandon path, 3*PTO and idle timer

[huitema]

Reading the draft-13 more closely, I see a bit of a contradiction between 3.3.3 and 3.4.

Section 3.3.3 on "idle timeout" says: "An endpoint can decide to close a path at any time, whether the path is in active use or not, by sending a PATH_ABANDON frame. It is not required to send a PATH_ABANDON frame at any specific point in time. For example, an endpoint may wait until it will anyway send another frame."

Section 3.4 on "Path Close" says: "If a peer sends a PATH_ABANDON frame but never receives a corresponding PATH_ABANDON frame, it might not be able to remove path state. It is left to the implementation to handle this unexpected behavior as it does not impact interoperability. If the endpoint is no longer willing to process the issued connection IDs for the abandoned path, it MAY close the connection, but SHOULD wait at least 3 PTOs after sending the PATH_ABANDON frame."

The text in 3.3.3 is motivated in part by radio management. On a mobile device, sending any packet requires powering up the radio, which consumes energy. It is better to power the radio once and send a few packets in a batch than to power the radio multiple time. But if the endpoint waits until "something else has to be sent", it may wait more than 3*PTO, and the peer MAY close the connection. Not good.

[mirjak]

These pieces of text were suppose to address two different cases (which I see now might not be super clear or at least could be clarified):

The peer sending the initial path_abandon may or may not do that at any point in time. However if you receive a path abandon you should reply immediately.

[mirjak]

How about this:

OLD
"It is not required to send a PATH_ABANDON frame at any specific point in time."

New
"For the initial PATH_ABANDON frame to close a path, it is not required to send a PATH_ABANDON frame at any specific point in time."

Good enough?

[huitema]

Yes, that's probably enough.