Abandon needs clarification

[mirjak]

The text says that both endpoint can send an abandon frame. However, if I understand the current text correctly it only says that the receiving peer of that frame can remove its state as the sender of the abandon frame indicated it will not send any more packets ion that path. However, the sender of the abandon frame can't remove its state until it also receives an abandon frame from the other end. That would mean a path can "half-open"...

Do we need to say something that that the receiver of an abandon frame SHOULD also send an abandon frame in response? Or MAY? Or MUST?

Or is the path considered completely closed as soon as an ACK for the packet containing the abandon frame is received? In this case we need to say that when an abandon frame is received, the receiver MUST not use that path anymore.

I think we need to clarify that!

Please provide a PR or let me know what the intention was and I can write something!

[huitema]

For me, ABANDON_PATH means "please stop sending on that path, I may soon stop listening". The peer should definitely stop sending on that path. It may want to keep listening for a short time, because some packets may still be sent out of order. It may also want to keep some context to process acknowledgement of packets previously sent on that path. The general guidance is to to wait for something like 3xRTO before dropping path management resource.

I don't think that we need symmetry, that both peers have to abandon the path before they can release resource. But we have to solve a potential path suicide problem. Suppose we have two paths, peer 1 abandons path #1, peer 2 abandon path #2. Now we have zero path, and the connection is closed -- unless the client promptly opens a new path #3. My original intention is that only the client ever sends an ABANDON_PATH, since only the client can initiate a new path, which dodges the path suicide issue.

[yfmascgy]

Good questions! For me, the issue is that when an endpoint decides to close a path, it is probably due to that the path condition is getting worse, which also means that further communication on that path may fail. When we use non-zero CID, as we should have at least one path that is working (if no path is working, the connection will be closed), and we are not constraint to send PATH_ABANDON frame on the same path that we want to close, the sender should be able to receive the ACK of PATH_ABANDON. But when we use null CID, we use path_id_type 0x02, which refers to the path where the packet is coming from, and hence, we are constraint to send PATH_ABANDON on the same path we want to close. In such a case, it is likely that the ACK of PATH_ABANDON will not be received, resulting in the "half-open" problem. Therefore, we should say sth like "when the sender moves into the "ABANDON_SENT" state, and after 3RTO, it should close the path even if it hasn't seen the PATH_ABANDON sent from its peer".

[yfmascgy]

Also, regarding when a path is considered completely closed, the current intention is that a path is considered closed when both the sender-side and the receiver-side resources of that path are released. The sender-side resources can be readily released when PATH_ABANDON is acked (We may need to retransmit the path_abandon). The receiver-side resources are released when the RETIRE_CID frame is received. However, when zero-CID is used, it is possible that an endpoint is not going to receive any RETIRE_CID frames, so the receiver-side resources are released 3RTO after sending out the PATH_ABANDON.

[mirjak]

I created PR #46. I think this is the biggest issue we need to address and agree on before submission of -00. So please review @huitema @Yanmei-Liu @qdeconinck !