idnits 2.17.1 draft-reddy-mmusic-ice-best-interface-pcp-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 (October 10, 2013) is 3851 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-07) exists of draft-reddy-mmusic-ice-happy-eyeballs-03 == Outdated reference: A later version (-07) exists of draft-wing-mmusic-ice-mobility-05 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC T. Reddy 3 Internet-Draft D. Wing 4 Intended status: Informational B. VerSteeg 5 Expires: April 13, 2014 R. Penno 6 Cisco 7 V. Singh 8 Aalto University 9 October 10, 2013 11 Improving ICE Interface Selection Using Port Control Protocol (PCP) Flow 12 Extension 13 draft-reddy-mmusic-ice-best-interface-pcp-00 15 Abstract 17 A host with multiple interfaces needs to choose the best interface 18 for communication. Oftentimes, this decision is based on a static 19 configuration and does not consider the link characteristics of that 20 interface, which may affect the user experience. 22 This document describes a mechanism for an endpoint to query the link 23 characteristics from the access router (the router at the other end 24 of the endpoint's access link) using a Port Control Protocol (PCP) 25 Flow Extension. This information influences endpoint's Interactive 26 Connectivity Establishment (ICE) candidate selection algorithm. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 13, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 64 3. Algorithm overview . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Changed Link Quality . . . . . . . . . . . . . . . . . . . 4 66 4. Multiple Interfaces . . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Multiple Interfaces for media streams . . . . . . . . . . . 5 68 4.2. Availability of New Interfaces . . . . . . . . . . . . . . 5 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 75 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 A.1. Delay Factor in Discovering the Link Characteristics . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 ICE [RFC5245] uses a prioritization formula to perform connectivity 82 checks, in which the most preferred address pairs are tested first 83 and when a sufficiently good pair is discovered, the ICE connectivity 84 tests are stopped. ICE prefers address pairs in the following order: 85 transport address directly attached to the endpoint's network 86 interface (host candidate), transport address on the public side of a 87 NAT (server reflexive candidate), and finally, transport address that 88 are allocated on a media relay (relayed candidate). This approach 89 works well for an endpoint with a single interface, but is too 90 simplistic for endpoints with multiple interfaces. The network 91 interfaces may have different link characteristics, but that will not 92 be known without the awareness of the upstream and downstream 93 characteristics of the access link. 95 In this document, an ICE agent [RFC5245] uses PCP Flow Extension 96 [I-D.wing-pcp-flowdata] to determine the link characteristics of the 97 host's interfaces, which influence the ICE candidate priority. 99 As this document explains the interworking of ICE and Port Control 100 Protocol (PCP) Flow Extensions, it is beneficial to first read the 101 Overview of ICE (Section 2 of ICE [RFC5245]) and PCP Flowdata Option 102 [I-D.wing-pcp-flowdata]. Additionally, PCP for WebRTC 103 [I-D.penno-rtcweb-pcp] describes the problems with traversing NATs 104 and firewalls, current techniques used to solve them and the PCP 105 solution in these scenarios. 107 2. Notational Conventions 109 This note uses terminology defined in ICE [RFC5245] and PCP 110 [RFC6887]. 112 3. Algorithm overview 114 The proposed algorithm is backward compatible with existing 115 implementations, and does not require any changes other than to the 116 selection of candidate priority. 118 When an endpoint first joins a network, it determines if the network 119 supports PCP Flow Extensions by following the procedures described in 120 [I-D.wing-pcp-flowdata]. Basically, the endpoint sends a PCP Flow 121 Extension probe packet, the response to which provides coarse 122 information on the link capabilities. After confirming that PCP Flow 123 Extensions are supported on that network interface, the ICE agent can 124 use PCP Flow Extensions on that interface (rather than STUN). 126 When a media session needs to be established, and the user and 127 operator controlled policies on an endpoint permit more than one 128 interface for a media session, the ICE agent uses PCP Flow Extensions 129 to (a) obtain a mapping from its NAT or firewall and (b) determine 130 the characteristics of the link. After receiving the PCP Flow 131 Extension responses from its various interfaces, the ICE agent sorts 132 the ICE candidates according to the link capacity characteristics. 133 ICE candidates from the interface which best fulfills the desired 134 flow characteristics is assigned the highest priority and the best 135 suited interface should be used to communicate with the TURN server 136 to learn the relayed candidate address. 138 The ICE agent calculates the priorities of host and server-reflexive 139 candidates based on the above steps and signals these candidates in 140 offer or answer to the remote peer. After the offer and answer are 141 exchanged, the participating ICE agents begin pairing the candidates, 142 ordering them into check lists to start the ICE connectivity check 143 phase and eventually select the pair of candidates that will be used 144 for real-time communication. 146 3.1. Changed Link Quality 148 It is possible that the characteristics of a link may change over 149 time, and therefore the ICE agent may want to move the media to a 150 different interface. For example, if a competing high-bandwidth flow 151 starts or finishes its data transmission; the DSL line rate might 152 have improved (or degraded); the link capacity may have been 153 dynamically increased (or decreased). When link quality changes in 154 such a fashion, the PCP Flow Extensions sends a PCP message to the 155 endpoint. Upon receiving the message, the ICE agent may decide to 156 move the active flow to a more suitable interface and performs ICE 157 restart to trigger the switch over of the media streams to the new 158 interface. 160 For ICE local relayed candidates, the ICE agent can switch to the 161 more suitable interface by refreshing its allocation with the TURN 162 server using the procedures explained in section 5 of Mobility using 163 TURN [I-D.wing-mmusic-ice-mobility]. Thus reusing the local relayed 164 candidate on a different interface even if the endpoint IP address 165 changes. Therefore, the ICE agent can switch over local relayed 166 candidate to the most suited interface that meets the requirements of 167 the media stream. This way, even without informing the SIP server 168 and remote peer, ICE agent can switch over a local relayed candidate 169 to the most suited interface which meets the requested flow 170 characteristics. 172 4. Multiple Interfaces 174 If multiple interfaces are available, the ICE agent can use PCP Flow 175 Extensions [I-D.wing-pcp-flowdata] to determine the best path. The 176 advantage is PCP can be used to select the most suitable interface 177 for the media streams. When an endpoint has multiple interfaces (for 178 example 3G, 4G, WiFi, VPN, etc.), an ICE agent can choose the 179 interfaces for media streams according to the path characteristics, 180 as discussed in the previous section. 182 4.1. Multiple Interfaces for media streams 184 If the requested flow characteristics for the media streams cannot be 185 handled by a single interface but by multiple interfaces then the ICE 186 agent performs the following steps: 188 o ICE agent based on the ICE connectivity results could select 189 multiple interfaces for the media session. For example, the ICE 190 agent selects to send the audio stream over the WiFi access point 191 because it offers (via PCP Flow Extensions) low delay, low packet 192 loss and average capacity of 120 Kbps, but for the video stream it 193 selects the 3G interface because it offers medium delay, medium 194 packet loss and average capacity of 500Kbps. 196 o Alternatively, the ICE agent on a mobile device may also want to 197 select the best suited interface among all the available 198 interfaces even if it does not serve the requested flow 199 characteristics for all the media streams, so that other 200 interfaces can be turned off to increase the battery life of 201 cellular connected devices such as smartphones or tablets. 203 4.2. Availability of New Interfaces 205 If the available interfaces do not meet the requested flow 206 characteristics then ICE agent can either proceed as usual using the 207 "Recommended Formula" explained in Section 4.1.2.1 of [RFC5245] to 208 prioritize the candidates or use the Happy Eyeballs Extension for ICE 209 algorithm proposed in [I-D.reddy-mmusic-ice-happy-eyeballs] for dual- 210 stack endpoint. When new interfaces become available then ICE agent 211 can use PCP Flow Extension to find if the newly available interfaces 212 meet the flow characteristics. When a PCP response is received from 213 at least one of the new interfaces and if it meets the requirements, 214 the endpoint can re-connect to the SIP proxy using the new interface. 215 The endpoint uses the candidates indicated in the previous PCP 216 response, it exchanges updated offer/answer to trigger ICE restart. 217 Once the ICE processing reaches the "Completed state", the ICE 218 endpoint can successfully switch the media session over to the new 219 interface. The interface initially used for communication can now be 220 turned off without disrupting communications. 222 5. IANA Considerations 224 None. 226 6. Security Considerations 228 Security considerations discussed in [RFC6887] are to be taken into 229 account. 231 7. Acknowledgements 233 Authors would like to thank Anca Zamfir for comments and review. 235 8. References 237 8.1. Normative References 239 [I-D.wing-pcp-flowdata] 240 Wing, D., Penno, R., and T. Reddy, "PCP Flowdata Option", 241 draft-wing-pcp-flowdata-00 (work in progress), July 2013. 243 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 244 (ICE): A Protocol for Network Address Translator (NAT) 245 Traversal for Offer/Answer Protocols", RFC 5245, 246 April 2010. 248 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 249 Selkirk, "Port Control Protocol (PCP)", RFC 6887, 250 April 2013. 252 8.2. Informative References 254 [I-D.penno-rtcweb-pcp] 255 Penno, R., Reddy, T., Wing, D., and M. Boucadair, "PCP 256 Considerations for WebRTC Usage", 257 draft-penno-rtcweb-pcp-00 (work in progress), May 2013. 259 [I-D.reddy-mmusic-ice-happy-eyeballs] 260 Reddy, T., Patil, P., and D. Wing, "Happy Eyeballs 261 Extension for ICE", 262 draft-reddy-mmusic-ice-happy-eyeballs-03 (work in 263 progress), October 2013. 265 [I-D.wing-mmusic-ice-mobility] 266 Wing, D., Reddy, T., Patil, P., and P. Martinsen, 267 "Mobility with ICE (MICE)", 268 draft-wing-mmusic-ice-mobility-05 (work in progress), 269 September 2013. 271 Appendix A. 273 A.1. Delay Factor in Discovering the Link Characteristics 275 Some concern has been expressed, that discovering the link 276 characteristics may consume more time than using STUN. However, STUN 277 will actually take more time than learning link characteristics, 278 because a STUN request/response traverses across more routers than a 279 PCP Flow Extension request. 281 Authors' Addresses 283 Tirumaleswar Reddy 284 Cisco Systems, Inc. 285 Cessna Business Park, Varthur Hobli 286 Sarjapur Marathalli Outer Ring Road 287 Bangalore, Karnataka 560103 288 India 290 Email: tireddy@cisco.com 292 Dan Wing 293 Cisco Systems, Inc. 294 170 West Tasman Drive 295 San Jose, California 95134 296 USA 298 Email: dwing@cisco.com 300 Bill VerSteeg 301 Cisco Systems, Inc. 302 5030 Sugarloaf Parkway 303 Lawrenceville 30044 304 USA 306 Email: billvs@cisco.com 307 Reinaldo Penno 308 Cisco Systems, Inc. 309 170 West Tasman Drive 310 San Jose, 95134 311 USA 313 Phone: 314 Email: repenno@cisco.com 315 URI: 317 Varun Singh 318 Aalto University 319 School of Electrical Engineering 320 Otakaari 5 A 321 Espoo, FIN 02150 322 Finland 324 Email: varun.singh@iki.fi 325 URI: http://www.netlab.tkk.fi/~varun/