Is RETIRE_PATH_ID needed?

[mirjak]

This is from the discussion on PR #292:

yfmascgy on Nov 21, 2023

What happens if the one endpoint doesn't how many path is needed? In the case of a deteriorating wifi, the endpoint wants to switch to 5G, but finds itself with no Path ID to use? What is the pre-allocating strategy?

**@Yanmei-Liu Yanmei-Liu on Nov 21, 2023

Endpoints just need to decide the max concurrent path and pre-allocate at lease one unused CID for each path Identifier. Endpoints don't need to decide which Path Identifier to use until client start a new path and choose one available CID with the unused Path Identifers.

@yfmascgy yfmascgy on Nov 21, 2023

I am thinking a situation where you want max of three paths. You have your first path established. Try to establish another two paths on the 2nd sim and 3rd sim but failed. Then you don't have a path ID to build a path on the 4th sim even though it is available to use and can give you in total 2 paths (< max_num_path)

@kazuho kazuho on Nov 21, 2023

Maybe using the scheme that we have for Connection IDs in QUIC v1 would drive the discussion.

If we do that, then

- the user of path IDs will send a TP indicating the number of paths from which it can send packets concurrently,
- the peer sends MAX_PATH_IDS frame signaling the maximum path ID the user can use (consider MAX_DATA or MAX_STREAMS as precedents),
- the user uses the path ids, and when it is done, sends a RETIRE_PATH_ID carrying the path id to be retired. We cannot use PATH_ABANDON here because it serves a different purpose and sent in the opposite direction,
- when receiving a RETIRE_PATH_ID frame, the peer may raise the limit advertised by MAX_PATH_IDS.

@Yanmei-Liu Yanmei-Liu on Nov 21, 2023

@kazuho 's idea is quite useful, I added these mechanism:

- TP initial_max_paths for the initial max Path ID limitation.
- MP_MAX_PATHS frames could solve this issue by raise the limit of Path Identifier.

We don't need a RETIRE_PATH_ID here because Path Abandon has already been a clear signal for Path ID retirement.

@kazuho kazuho on Nov 21, 2023

Thanks. I’m afraid PATH_ABANDON cannot be used, as it is sent in the different direction. We need a new frame.

IIUC, PATH_ABANDON is a frame sent by the issuer of CIDs (who will also the issuer of path IDs in the new design). It is a frame that “requests the peer” to abandon the path.

What we are looking for now is a frame that is sent by the receiver (i.e., the user) of the CIDs / path IDs, that carries the fact that the path has been abandoned.

@Yanmei-Liu Yanmei-Liu on Nov 21, 2023

I think it's fine for the issuer of Path IDs to take responsibility of retiring them.
Besides, the receiver of the Path IDs could also use the Path Abandon to trigger the retirement of Path Identifier for both sides.

@kazuho kazuho on Nov 21, 2023

> I think it's fine for the issuer of Path IDs to take responsibility of retiring them.
Consider the case of an endpoint deciding to stop using a path on which it sends packets. That endpoint has to retire the CID (or the path identifier in the new design) that is issued by the peer.

In -05, we use RETIRE_CONNECTION_ID as a signal. But in the new design, we are splitting CIDs and path IDs. So we need a new frame.

> Besides, the receiver of the Path IDs could also use the Path Abandon to trigger the retirement of Path Identifier for both sides.
The path ID space will be different for each endpoint, won't it be? This is because each endpoint has its own view of paths, similar to Connection IDs.

If we are to use PATH_ABANDON for requesting retirement of path ID that the endpoint issued and also for signalling that retirement of a path ID that the peer issued, we need to add a field indicating to which side of path ID space (i.e., the endpoint or the peer) that the frame is referring.

But as the role of the frame will be different (as said, one endpoint signals the request to retire path ID, whereas the other side signals the fact that the path ID has been retired; that is how PATH_ABANDON and RETIRE_CONNECTION_ID work today), it might be better to have a different frame.

@yangfurong yangfurong on Nov 22, 2023

>The path ID space will be different for each endpoint, won't it be? This is because each endpoint has its own view of paths, similar to Connection IDs.

Why can't we use the same path ID space for both endpoints? I understand that it is necessary to have different spaces when the DCID sequence number is used for identifying paths. But, it is a result of using DCID sequence numbers as path identifiers which are not stable during the lifetime of paths. Since we are going to use explicit and stable path IDs, is it still necessary to have different ID spaces?

@yangfurong yangfurong on Nov 22, 2023

If the two endpoints use the same path ID for a specific path, the situation becomes simpler.

1. When the client finds the establishment of path1 and path2 fails, it should send two PATH_ABANDON frames to the server;
2. Once the server receives the PATH_ABANDON frames, it should reply with two PATH_ABANDON frames and issue new CIDs associated with path3 and path4;
3. When the client receives PATH_ABANDON frames from its peer, it should also issue new CIDs associated with path3 and path4;
4. Once the client notices that both endpoints have available CIDs for the next path to be created and the active path count is less than the limit, it can request to open a new path.

@Yanmei-Liu Yanmei-Liu on Nov 23, 2023

Using the same Path ID for both sides will introduce more negotiation and frame order dependency, we'd better avoid that.

@Yanmei-Liu Yanmei-Liu on Nov 23, 2023

I'm considering add a retirement frame for Path ID.
As @kazuho points out, we need retirement signals for both sides:

- Although in normal situations Path Abandon could release the Path ID associated on both sides, but there're situations when endpoint try to create a new path by Path Challenge but the peer doesn't receive the packet and don't know what happened to the Path ID consumed.
- Also, when endpoint allocates new CIDs for new Path IDs, it will not know whether it touch the max limit or not, as we don't have a retirement signal for Path ID and peer could maintain the history Path IDs. It's the same situation happens to CIDs, and that's why we need retirement frame and Retire Prior To field.

@michael-eriksson michael-eriksson on Nov 23, 2023

> Using the same Path ID for both sides will introduce more negotiation and frame order dependency, we'd better avoid that.

Why is that? The connection IDs are signalled before the path is used and will uniquely identify the path; the first time a peer sees a connection ID used in a packet it can directly map the CID to a path which has a single stable path identifier. No negotiation or other extra signalling is needed.

If/when the protocol is extended to allow servers to initiate paths, the protocol should use even/odd path IDs, exactly like stream IDs are already used.

@huitema huitema on Nov 26, 2023

We need more discussion of that specific point. The current situation is ambiguous. For example, what does "Abandon path 17" means? I am pretty sure that some implementations are going to get confused between "the ID chosen by the server" and "the ID chosen by the client".

@huitema huitema 3 weeks ago

I think that if we go through the trouble of changing the current solution, we should go for having the same path ID in both directions. It will make management much simpler, and it is not very hard, see later comments.

[Yanmei-Liu]

If we let Path Abandon to do the job of retiring the associated Path ID, we don't need RETIRE_PATH_ID as far as I know.

[huitema]

See issue #313, which is somewhat related.

[mirjak]

Please continue discussion in #313