| Network Working Group | P. Thatcher |
| Internet-Draft | H. Zhang |
| Intended status: Standards Track | T. Brandstetter |
| Expires: September 22, 2016 | |
| March 21, 2016 |
ICE Network Cost: Dynamically selecting ICE candidate pairs based on relative cost of network interfaces
draft-thatcher-ice-network-cost-00
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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:
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 [RFC2119].
This specification makes use of all terminology defined by the protocol for Interactive Connectivity Establishment in [RFC5245].
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:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network ID | Network Cost |
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
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC5245] | Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010. |