ICE Network Cost: Dynamically selecting ICE candidate pairs based on
relative cost of network interfaces
Google747 6th St SKirklandWA98033USApthatcher@google.comGoogle747 6th St SKirklandWA98033USAhonghaiz@google.comGoogle747 6th St SKirklandWA98033USAdeadbeef@google.com
This document describes an extension to the Interactive
Connectivity Establishment (ICE) that enables ICE agents to
exchange information about the relative cost of network interfaces
and dynamically choose the selected ICE candidate pair based on
the cost of both the local and remote network interfaces. For
example, if a cellular network interface has a higher cost than a
Wi-Fi network interface, the ICE agents can use that information
to prefer candidate pairs with Wi-Fi rather than cellular when
possible, and only use cellular when necessary.
This document additionally describes a second piece of
information, network ID, that goes along with the network cost
and can be used to know when a network interface has changed,
even if two network interfaces have the same network cost.
In certain network conditions, ICE agents may prefer to use a
network interface with a lower cost (for a definition of cost
chosen by the ICE agent, which need not be directly related to
monetary costs). If the controlling side has such a preference,
it can unilaterally nominate a candidate pair with the network
interface with lower cost, but if either the controlling side has
no such preference, or it would like to take the controlled side's
preference into account, it cannot do so unless the controlled
side provides information about its network cost.
Additionally, if the network interface of the controlled side
changes (such as by using TURN mobility), the controlling side
needs updated information from the controlled side.
The controlling side may also wish to select candidate pairs not
only based on the relative cost between candidate pairs, but also
the cost relative to the quality of the network path. For
example, if Wi-Fi has a much higher cost, but cellular is much
higher quality, the controlling side may select cellular even
though it's higher cost. To do so, the controlled side must
provide information about the network cost relative to the
network quality. For example, if a network cost 10 is equivalent
to 100ms network RTT, a Wi-Fi with cost 0 and RTT 150ms will have
equal preference to a cellular with cost 10 and RTT 50ms.
Although the controlled side already communicates an ICE candidate
priority, that candidate attribute doesn't meet the needs of this
situation for the following reasons:
Candidate priority affects ICE check ordering as well as
candidate pair preference, which is undesirable in this
situation, where the ICE check order should be maintained, but
the candidate pair preference should be changed.
Candidate priority cannot change when the network interface
changes (such as by using TURN mobility)
Candidate priority is only defined relative to other
priorities, and can't be compared against network quality in a
meaningful way.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in .
This specification makes use of all terminology defined by the
protocol for Interactive Connectivity Establishment in
.
A value indicating how much an ICE agent would prefer to not
use a given network interface. This may be, but need not be
related to monetary costs of using the network interface.
An ID that uniquely identifies a network interface.
Network cost is an integer in the range 0-999, where larger values
indicate a stronger preference for not using that network
interface.
Each network interface SHOULD have a unique network ID, in the
range of 0 to (2^16)-1.
ICE agents MUST signal network cost on each ICE candidate if the
cost is non-zero. ICE agents MUST signal network ID on each ICE
candidate.
For example, in an SDP candidate line, the attributes could be
signaled as "network-cost 100 network-id 1".
To communicate a change in network cost or to communicate network
cost for peer reflexive candidates, the following STUN attribute
is defined:
A 32-bit integer where the first 16 bits are the network ID and
the second 16 bits are network cost:
In the initial ICE checks, ICE agents MUST communicate a network
cost and network ID if either is non-zero. The ICE agent MUST
communicate new values in subsequent ICE checks if the network
cost or network ID changes.
If network cost is communicated via either signaling or STUN
attribute, the controlling side SHOULD use the network cost of the
controlled side as part of the criteria to determine which
candidate pair to select. It SHOULD use network cost before using
candidate priorities (network cost takes precedence over candidate
priority), and it SHOULD NOT change the ICE check order based on
network cost.
If the controlling side chooses to balance network cost against
network quality, it is RECOMMENDED to treat a difference in
network cost of 10 as equivalent of a change in network RTT of
100ms.
Any time the controlling side sees a change in the network cost
from the controlled side, it MUST recalculate which candidate pair
to select and nominate the newly selected candidate pair, if it
has changed.
This specification requests no actions from IANA.
TODO
TODO