Should PATH_STATUS be an extension?

[ehaydenr]

While PATH_STATUS with active/standby may satisfy a particular use case, does it make sense to include in the core MPQUIC draft? My concerns are:

• Given PATH_STATUS's limited expressibility, will applications instead almost always reach for some future extension?
• Will new extensions need to consider how they interact with PATH_STATUS? Do they complement PATH_STATUS? Override it? This seems avoidable if PATH_STATUS is broken out.

[huitema]

The PATH_STATUS as currently defined solves a very real issue. Take the classic Wi-Fi + cellular scenario. Both work, but the cellular traffic is expensive, so the client wants to tell the server to keep it ready, but not use it unless it is the only remaining solution. RFC 9000 solves that with the "validating traffic" trick: the client sends data on the path that it wants to use, and the server deduces that it should sending on that path too. But this is a brittle solution. Having explicit signals like "this path is available" or "keep this path on standby" solves that in a much more robust way.

And yes, we will probably see extensions. For example, we heard a talk making the case for "use this path but only for priority traffic", which is a different way of making a path available.

[ehaydenr]

Thanks for the additional context - particularly your point about how things are implicit in RFC 9000 (something that no longer really works in a multipath world).

Thinking further about my second point, I imagine extensions could maintain compatibility with PATH_STATUS by simply excluding "standby" paths from the set of paths to make scheduling decisions over.

[huitema]

The multipath specification already says that: only schedule data traffic on the paths that are deemed available, not on the standby paths, unless there are no available paths.