Connection Manager

[stv0g]

We might want to think about introducing a per-peer connection manager which handles zero, one or more concurrent ICE agents.

Motivation

Connection Upgrades

ICE does not automatically upgrade to better candidate pairs once they become available (e.g. new network interface comes up, upstream topology/routing changes).

Hence, we could periodically create new ICE agents/connections in the background to probe for better candidate pairs and only switch over the WireGuard traffic if we have found a better alternative.

Connection Fallbacks

Keeping multiple ICE connections between two pairs could allow us to quick failover to another candidate pair if the current one breaks.

This is only really of advantage if a quick failover is required and a normal ICE restart would take too long.

Passive peers

In setups with a very high number of peers a fully meshed VPN topology might be undesirable as in results in an excessive number of ICE connections and open ports.

A connection manager could put peers into a passive state in which we do not attempt to establish a direct connection, but rather fall back to dynamic routing (#10).

The connection manager could nominate peers to become active in case we see direct connection attempts or increased traffic to networks connected to that peer.

It also opens a whole new research question: which partial mesh is the optimal one?

See also: https://github.com/pion/ice/issues/543