Note that path state cannot be removed without reception of PATH_ABANDON

[mirjak]

fixes #471

[qdeconinck]

LGTM.

[huitema]

I do not think this paragraph is necessary. I also think it is probably wrong. Suppose that I put a path in a "locally abandoned" state, and:

• send a last ACK for the packets received so far,
• consider all the packets sent so far and not acknowledged,
• drop all incoming packets on that path without processing them.

I have at that point removed 99% of the path state -- the only resource that I need to keep is the path identifier, and I will only remove that when the ABANDON is received. But I have removed the bulk of the memory allocation: the copy of packets waiting for an ACK, the list of packets received from the peer that should be acked, probably the CID allocated for the path as well.

Yes, that will lead to packet loss, but so what? I have sent the ABANDON already, the peer should not be using the path, if it keeps doing so, too bad. There is never a guarantee that a packet will be received, and there is no protocol violation if the packets that were dropped are not acked.

Which points that [see next comment]

[mirjak]

@huitema looks like you comment above is half finished only...?

So what exactly is wrong about the current text?

I proposed this PR because the agreement in issue #471 that we wanted to note this issue. Please continue discussion there if you changed your mind and think we should not do anything.

[huitema]

The only recommendation that we should make is to not take any drastic action too soon. For example, it would be bad if application waited less than 3 PTO before closing the connection because they have not received a PATH_ABANDON yet.

[mirjak]

I entered your proposed change which is fine for me. But based on your second comment, do you want to add anther sentence like:

"An endpoint SHOULD NOT remove path state earlier than 3 PTOs after sending the PATh_ABANDON frame".

?

[huitema]

Yes, please add the warning against removing state too soon.