This currently just says we never switch away from user transports, even if "better" ones are available.

We need to figure this out before merging. To reason about this, I'm thinking about example user transports:

• WifiAware
• WebRTC
• In-process simulated networks
• Bluetooth

I'd say that we should prefer IP paths if the work and have lower RTT.
So that'd mean that here we're checking if current_rtt >= new_rtt + RTT_SWITCHING_MIN_IP similar to above. And if that is true, we resolve to best_ip_path, if not, we keep the user path.

Additionally, we should check if we have a user transport available, and switch away from None, Relay or Ip to a user path in the match cases above, if the user transport ends up having a lower RTT.

Tbh, this could become quite complicated quickly. E.g. maybe some user transports actually want to stay in the background (with PATH_BACKUP), and only be used if (once we have an API for that) a stream is specifically attached to that path.
We should probably think about how much wiggle-room we have if we'd set the API in stone for 1.0.

See the new API. Basically this is solved by #3870. For each transport (=address type) you can have a rtt bias (positive or negative), and you can configure for each address type if it is a normal transport or a transport of last resort.

Then within each group transports compete according to their biased rtt, and there is stickiness. For switching the group there is no stickiness.

should this account for custom transports in some form?

Not sure. A custom path is just another path, so I guess this does not have to be special cased for custom paths.

we special case IP paths in here, that's why I am wondering

Oh god. I guess you are right.

We are using is_ip as a "this is a good path" stand-in for now. Not just here, but in a lot of places.

I guess we would have to change is_ip with checking if the path is a "primary". But you can't see that from an addr - custom transports can be either. So it would have to be a lookup in bias_map.

Something like this:

+        let is_primary = |addr: &transports::Addr| {
+            self.transport_bias
+                .get(addr)
+                .transport_type == transports::TransportType::Primary
+        };
+
         for (conn_id, conn_state) in self.connections.iter() {
             for (path_id, path_remote) in conn_state
                 .open_paths
                 .iter()
-                .filter(|(_, addr)| addr.is_ip())
+                .filter(|(_, addr)| is_primary(addr))
                 .filter(|(_, addr)| *addr != selected_path)
             {
-                if conn_state.open_paths.values().filter(|a| a.is_ip()).count() <= 1 {
+                if conn_state.open_paths.values().filter(|a| is_primary(a)).count() <= 1 {
                     continue; // Do not close the last direct path.
                 }
                 if let Some(path) = conn_state

Without custom transports is_primary returns true only for ip, so the behaviour would be unchanged.

There are only a few non-test places other than this where is_ip is used. BUT... I think custom transports as implemented now introduce the concept of a backup transport, that gets sorted together with the relay transports, but is not a relay.

I wonder if we should just drop this and say that all custom transports are direct. They would have to compete with Ip transports on the basis of their (biased) rtt. That would probably simplify not mixing up all the relay special cases with custom transports.

You could flip is_ip to just !is_relay and call it a day...

I am honestly not sure what to do here yet, lets make a todo/note in the comment and open an issue about it, so we don't forget about it