PATH_AVAILABLE/STANDBY vs. local API preference

[Yanmei-Liu]

When implementing -06 draft, we need to find out what to do when the signal from the peer(representing by the PATH_AVAILABLE/STANDBY frames) does not match the local API preference. There are several possibilities(mentioned by @Huitema):

1. Local always win. Simple, but it allows the server to bypass the client preferences.
2. Remote always win.
3. Client always win.
4. Server always win.
5. Most restrictive wins: if local says available and remote say standby, keep it as standby.

Although the strategy is depending on the implementation, making the strategy clear about how to use PATH_AVAILABLE/STANDBY Frames is quite important in the draft.

So we track the issue here and hope to hear more voice from different people.

[mirjak]

We tried to clarify in the draft that these frames are only a recommendation and there is no requirement to follow this recommendation (there is also no way to enforce that, except closing/not opening the path). Therefore the final sending decision is left to the implementation. I don't think this is something we even could or should standardise as it will depend on the application and other local knowledge.

[kazuho]

I agree with @mirjak that the current design is correct.

As stated in https://github.com/quicwg/multipath/issues/283#issuecomment-1793634282, I think what we have is a terminology issue and that is confusing us.

[Yanmei-Liu]

Although these Frames are preference(recommendation) not requirements, I still think we need more editorial guidance on this issue. When people write implementations, they would like to get deterministic results instead of vague response.

[mirjak]

@Yanmei-Liu what kind of additional guidance do you think we should give?

[mirjak]

Closing this issue. Please continue discussion in issue #283