Discuss what to do if path_status is detected as lost or needs to be resend otherwise

[mirjak]

We might also discuss somewhere that you probably need to send an update if the peer changes the CID on that path. But maybe that a bit more discussion we need to have here. Maybe in this case it's better if the path_status frame could hold information for multiple CID or even provide somehow an assignment to a certain path status for future CID, so if then endpoint want to change it's CID on a path it can use a CID that is already assigned to the same property...?

[LPardue]

Discussed at IETF 116: more discussion is required

[mirjak]

Thinking for about this further and following the loose path ID model, we can actually not really restrict the signalling to only CIDs that are already in use because we don't have a good understanding for which CIDs at any point in time are "in active use". So that means an indicated path status could relate to any issued CID and we would leave it actually to the implementation if they want to "assign" a certain set of CIDs to a certain kind of path status in advance or only after a CID is observed on a path.

Effectively this, however, also means that an endpoint could provide only one CID for active use and all others for stand-by only, basically telling the other side to always only use one active path at a time. But not sure if that's overly great to have that as an implicit limitation. Or maybe it's a useful feature?

One more thought is that we could potentially also provide the path status at the time of issuing the CID (e.g. replacing the NEW_CONNECTION_ID frame with a new frame). However, you might still want a way to change the path state later... or not and you "just" change the CID instead...?

[mirjak]

This issue is on hold until we decide what to do with the PATH_STATUS frame, see issue #186

[mirjak]

This can be closed if PR #277 gets merged.