Sending PATH_STANDBY before the connection ID is used is pointless

[michael-eriksson]

The -06 draft allows a peer to send a PATH_STANDBY frame for a particular connection ID (CID) before it is used:

A PATH_STANDBY frame MAY be bundled with a NEW_CONNECTION_ID frame
[...] in order to indicate the preferred path usage
before [...] path initiation.

From the definition of PATH_STANDBY:

Destination Connection ID Sequence Number:  The sequence number of
   the Destination Connection ID used by the receiver of this frame
   to send packets over the path the status update corresponds to.

When the path is set up, each endpoint freely choses a destination CID between the CIDs that the peer has issued. This means that resulting preferred path usage depends on which CID the peer happens to chose.

I think that the current path identification model is very confusing, and this observation is another indication in that direction.

[mirjak]

First, just because you can send a path status for a CID that is not used yet, it doesn't mean that you have to do it. Second, yes if a path status was sent and a sender start using the CID, it also selects that path status, however, the receiver can update the path status anytime.

I do see a problem here to fix. However, the current approach provides more flexibility in usage of path status information in future.

Can you please explain which problem you thinks needs solving? Other I would propose to close this issue and continue discussion in issue #214. Thanks!

[huitema]

The only issue that I find in practice is a potential race condition -- but this is very mild. Take the somewhat common case in which a client has a connection working over Wi-Fi and wants to create a standby path over Cellular to enable fail-over. The client will create a path using path challenge, etc., and will then send the Path_Standby frame as soon as the path is created -- as @michael-eriksson points out, sending that sooner is a crap shot, because the client does not know which CID the server will pick. But the Path Standby frame or Path Available can be delayed for some time, for example in case of loss recovery. In that interval, the server will follow its default sending policy, which may not be what the client wants.

I think this is solved nicely if we keep the old validation process of RFC 9000 as the default. If the server has not yet received a Path Standby or Path Available frame, it follows RFC 9000 -- which is "standby until data is received from the client".

[mirjak]

Actually I think you can address that case with the current approach. E.g. if you want only one active path, you can simply set all issued but not used yet CIDs to standby.

[kazuho]

@mirjak

Actually I think you can address that case with the current approach. E.g. if you want only one active path, you can simply set all issued but not used yet CIDs to standby.

This is true, though I think my preference goes to stating that a path starts with either active or standby, rather than a third state.

Considering that endpoints can only signal active or standby, I do not think there is a reason to have the third state.

We can just state that the state starts with standby (or active). Then, only endpoints that want to change the state would be required to send a frame.

[mirjak]

I think the path just starts with no state. The state is really just the guidance or rather recommendation the other end gives you. In the absence of any explicitly signal, you have to solely rely on your local knowledge to make a sending decision. However, it can be your local policy to not use any path initially (until you receive a path status or e.g. data packets). But again, it's solely a local policy and I don't think it can be enforced or should be standardised.

Btw. we just changed that you effectively don't have to wait until path validation concluded before you are allowed to send non-probing packets. That would be the other option to require to wait until path validation concluded with gives the other end the chance to send you a path status if needed. however, I think that has more drawbacks.

[kazuho]

@mirjak

I think the path just starts with no state. The state is really just the guidance or rather recommendation the other end gives you. In the absence of any explicitly signal, you have to solely rely on your local knowledge to make a sending decision. However, it can be your local policy to not use any path initially (until you receive a path status or e.g. data packets). But again, it's solely a local policy and I don't think it can be enforced or should be standardised.

I think the question is if having that kind of design helps some endpoints.

In case of having peers that do not send PATH_ACTIVE / PATH_STANDBY frames, it does not matter if the initial state is "default" or "standby." This is because if all paths are standby, an endpoint is going to choose whichever path for sending data.

In case of having peers that send PATH_ACTIVE / PATH_STANDBY frames, it would be helpful to state that a path initially starts with either active or standby, because that reduces frames to be sent and increases predictability.

Is there something that I'm missing?

Btw. we just changed that you effectively don't have to wait until path validation concluded before you are allowed to send non-probing packets. That would be the other option to require to wait until path validation concluded with gives the other end the chance to send you a path status if needed. however, I think that has more drawbacks.

Yeah, until path is validated, an endpoint can only send as much as 3x that it has received. I do not think we need to make things complicated to reduce that 3x to something smaller.

[huitema]

I think we have to state explicitly what we mean by standby. We broadly agree, but I am concerned that some other developers with treat receiving packets on standby path is a protocol violation. That could cause interop issues.

On the other hand, we also don't want the peers to ignore standby requests completely. That would cause operational issues.

[kazuho]

@huitema

I think we have to state explicitly what we mean by standby. We broadly agree, but I am concerned that some other developers with treat receiving packets on standby path is a protocol violation. That could cause interop issues.

+1. I might argue that both "available" and "standby" are confusing as terms.

That is because the peer is allowed to send packets on paths that are in "standby." In fact, they would be forced to, if all of the available paths are declared as "standby."

This boolean state is merely indications of preference, it would make sense to rename them to better reflect that.

Maybe something like "preferred" / "backup" might eliminate the confusion.

[yfmascgy]

@kazuho +1. I agree, I think we need a better terminology.

[Yanmei-Liu]

Actually in my opinion "prefered" is a choice made by the sender's scheduler algorithm,
but I agree with that "backup" is a more proper name instead of "standby".

[mirjak]

It looks like the only proposed change here is now to rename "standby" to "backup". I'm labelling the issue as "editorial" for now. Maybe we can quickly confirm at the IETF-120 meeting if we want to rename the frame or not!

[mirjak]

As discussed in the IETF-120 session, we will rename the frame to PATH_BACKUP and then close this issue without further action.

I created PR #427

[mirjak]

Closing this issue as PR #427 was merged.