idnits 2.17.1 draft-thatcher-ice-network-cost-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2957 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Thatcher 3 Internet-Draft H. Zhang 4 Intended status: Standards Track T. Brandstetter 5 Expires: September 22, 2016 Google 6 March 21, 2016 8 ICE Network Cost: Dynamically selecting ICE candidate pairs based on 9 relative cost of network interfaces 10 draft-thatcher-ice-network-cost-00 12 Abstract 14 This document describes an extension to the Interactive Connectivity 15 Establishment (ICE) that enables ICE agents to exchange information 16 about the relative cost of network interfaces and dynamically choose 17 the selected ICE candidate pair based on the cost of both the local 18 and remote network interfaces. For example, if a cellular network 19 interface has a higher cost than a Wi-Fi network interface, the ICE 20 agents can use that information to prefer candidate pairs with Wi-Fi 21 rather than cellular when possible, and only use cellular when 22 necessary. 24 This document additionally describes a second piece of information, 25 network ID, that goes along with the network cost and can be used to 26 know when a network interface has changed, even if two network 27 interfaces have the same network cost. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 22, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Choosing a value for network cost and network ID . . . . . . 3 66 4. Signaling network cost and network ID . . . . . . . . . . . . 4 67 5. STUN attribute for network cost and network ID . . . . . . . 4 68 6. Interpreting network cost and network ID . . . . . . . . . . 4 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 72 10. Normative References . . . . . . . . . . . . . . . . . . . . 5 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 75 1. Introduction 77 In certain network conditions, ICE agents may prefer to use a network 78 interface with a lower cost (for a definition of cost chosen by the 79 ICE agent, which need not be directly related to monetary costs). If 80 the controlling side has such a preference, it can unilaterally 81 nominate a candidate pair with the network interface with lower cost, 82 but if either the controlling side has no such preference, or it 83 would like to take the controlled side's preference into account, it 84 cannot do so unless the controlled side provides information about 85 its network cost. 87 Additionally, if the network interface of the controlled side changes 88 (such as by using TURN mobility), the controlling side needs updated 89 information from the controlled side. 91 The controlling side may also wish to select candidate pairs not only 92 based on the relative cost between candidate pairs, but also the cost 93 relative to the quality of the network path. For example, if Wi-Fi 94 has a much higher cost, but cellular is much higher quality, the 95 controlling side may select cellular even though it's higher cost. 96 To do so, the controlled side must provide information about the 97 network cost relative to the network quality. For example, if a 98 network cost 10 is equivalent to 100ms network RTT, a Wi-Fi with cost 99 0 and RTT 150ms will have equal preference to a cellular with cost 10 100 and RTT 50ms. 102 Although the controlled side already communicates an ICE candidate 103 priority, that candidate attribute doesn't meet the needs of this 104 situation for the following reasons: 106 o Candidate priority affects ICE check ordering as well as candidate 107 pair preference, which is undesirable in this situation, where the 108 ICE check order should be maintained, but the candidate pair 109 preference should be changed. 111 o Candidate priority cannot change when the network interface 112 changes (such as by using TURN mobility) 114 o Candidate priority is only defined relative to other priorities, 115 and can't be compared against network quality in a meaningful way. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 This specification makes use of all terminology defined by the 124 protocol for Interactive Connectivity Establishment in [RFC5245]. 126 Network Cost A value indicating how much an ICE agent would prefer 127 to not use a given network interface. This may be, but need not 128 be related to monetary costs of using the network interface. 130 Network ID An ID that uniquely identifies a network interface. 132 3. Choosing a value for network cost and network ID 134 Network cost is an integer in the range 0-999, where larger values 135 indicate a stronger preference for not using that network interface. 137 Each network interface SHOULD have a unique network ID, in the range 138 of 0 to (2^16)-1. 140 4. Signaling network cost and network ID 142 ICE agents MUST signal network cost on each ICE candidate if the cost 143 is non-zero. ICE agents MUST signal network ID on each ICE 144 candidate. 146 For example, in an SDP candidate line, the attributes could be 147 signaled as "network-cost 100 network-id 1". 149 5. STUN attribute for network cost and network ID 151 To communicate a change in network cost or to communicate network 152 cost for peer reflexive candidates, the following STUN attribute is 153 defined: 155 A 32-bit integer where the first 16 bits are the network ID and the 156 second 16 bits are network cost: 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Network ID | Network Cost | 163 In the initial ICE checks, ICE agents MUST communicate a network cost 164 and network ID if either is non-zero. The ICE agent MUST communicate 165 new values in subsequent ICE checks if the network cost or network ID 166 changes. 168 6. Interpreting network cost and network ID 170 If network cost is communicated via either signaling or STUN 171 attribute, the controlling side SHOULD use the network cost of the 172 controlled side as part of the criteria to determine which candidate 173 pair to select. It SHOULD use network cost before using candidate 174 priorities (network cost takes precedence over candidate priority), 175 and it SHOULD NOT change the ICE check order based on network cost. 177 If the controlling side chooses to balance network cost against 178 network quality, it is RECOMMENDED to treat a difference in network 179 cost of 10 as equivalent of a change in network RTT of 100ms. 181 Any time the controlling side sees a change in the network cost from 182 the controlled side, it MUST recalculate which candidate pair to 183 select and nominate the newly selected candidate pair, if it has 184 changed. 186 7. IANA Considerations 188 This specification requests no actions from IANA. 190 8. Security Considerations 192 TODO 194 9. Acknowledgements 196 TODO 198 10. Normative References 200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 201 Requirement Levels", BCP 14, RFC 2119, 202 DOI 10.17487/RFC2119, March 1997, 203 . 205 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 206 (ICE): A Protocol for Network Address Translator (NAT) 207 Traversal for Offer/Answer Protocols", RFC 5245, 208 DOI 10.17487/RFC5245, April 2010, 209 . 211 Authors' Addresses 213 Peter Thatcher 214 Google 215 747 6th St S 216 Kirkland, WA 98033 217 USA 219 Email: pthatcher@google.com 221 Honghai Zhang 222 Google 223 747 6th St S 224 Kirkland, WA 98033 225 USA 227 Email: honghaiz@google.com 228 Taylor Brandstetter 229 Google 230 747 6th St S 231 Kirkland, WA 98033 232 USA 234 Email: deadbeef@google.com