idnits 2.17.00 (12 Aug 2021) /tmp/idnits34406/draft-uberti-mmusic-nombis-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 09, 2015) is 2623 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) ** Obsolete normative reference: RFC 6336 (Obsoleted by RFC 8839) == Outdated reference: draft-ietf-rtcweb-stun-consent-freshness has been published as RFC 7675 == Outdated reference: A later version (-04) exists of draft-williams-peer-redirect-03 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Uberti 3 Internet-Draft Google 4 Intended status: Standards Track J. Lennox 5 Expires: September 10, 2015 Vidyo 6 March 09, 2015 8 Improvements to ICE Candidate Nomination 9 draft-uberti-mmusic-nombis-00 11 Abstract 13 This document makes recommendations for simplifying and improving the 14 procedures for candidate nomination in Interactive Connectivity 15 Establishment (ICE). 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 10, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Goals and Requirements . . . . . . . . . . . . . . . . . . . 3 54 3.1. Minimize Call Setup Latency . . . . . . . . . . . . . . . 3 55 3.2. Allow Controlling Endpoint to Make Dynamic Decisions . . 3 56 3.3. Allow Selected Pair Change At Any Time Without Signaling 4 57 3.4. Allow Continuous Addition of Candidates . . . . . . . . . 4 58 3.5. Maintain Backwards Compatibility . . . . . . . . . . . . 4 59 3.6. Minimize Complexity Increase . . . . . . . . . . . . . . 5 60 4. Deprecating Aggressive Nomination . . . . . . . . . . . . . . 5 61 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.3. Backwards Compatibility . . . . . . . . . . . . . . . . . 6 64 4.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Introducing Continuous Nomination . . . . . . . . . . . . . . 7 66 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.3. Backwards Compatibility . . . . . . . . . . . . . . . . . 9 69 5.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.4.1. Switching Between Pairs Based on RTT . . . . . . . . 9 71 5.4.2. Switching To A New TURN Server . . . . . . . . . . . 9 72 5.4.3. Switching From WLAN to WWAN . . . . . . . . . . . . . 10 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 9.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 Interactive Connectivity Establishment (ICE) attempts to find the 85 'best' path for connectivity between two peers; in ICE parlance, 86 these paths are known as 'candidate pairs'. During the ICE process, 87 one endpoint, known as the 'controlling' endpoint, selects a 88 candidate pair as the best pair; this action is known as nomination. 89 ICE supports two different mechanisms for performing nomination, 90 known as Regular Nomination, and Aggressive Nomination. 92 However, each of these modes have flaws that restrict their 93 usefulness. Regular Nomination, as currently speced, requires a best 94 pair to be chosen before media transmission can start, causing 95 unnecessary call setup delay. Aggressive Nomination, while avoiding 96 this delay, gives the controlling endpoint much less discretion into 97 which candidate pair is chosen, preventing it from making decisions 98 based on dynamic factors such as RTT or loss rate. Needless to say, 99 the presence of both modes also adds nontrivial complexity. 101 Lastly, ICE is currently defined as a finite process, where the 102 decision on the optimal candidate pair is made during call setup and 103 infrequently (if ever) changed. While this may be acceptable for 104 endpoints with static network configurations, it fails to meet the 105 needs of mobile endpoints, who may need to seamlessly move between 106 networks, or be connected to multiple networks simultaneously. In 107 these cases, the controlling endpoint may want to maintain multiple 108 potential candidate pairs, and make dynamic decisions to switch 109 between them as conditions change. 111 To address these challenges, this document makes two proposals for 112 refactoring ICE nomination - merging Regular and Aggressive 113 Nomination, and introducing a new mode, known as Continuous 114 Nomination. This makes ICE substantially more flexible without 115 increasing complexity. 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 3. Goals and Requirements 125 The goals for improved ICE nomination are enumerated below. 127 3.1. Minimize Call Setup Latency 129 Modern ICE agents will often have multiple network interfaces and 130 multiple servers from which to obtain ICE candidates. While some ICE 131 checks may succeed quickly, finishing the entire set of checks can 132 easily take multiple seconds; this concern is discussed in [RFC5245], 133 Section 8.1.1.1. As a result, ICE endpoints MUST be able to start 134 transmitting media immediately upon a successful ICE check, and MUST 135 retain the ability to switch if a better candidate pair becomes 136 available later. 138 3.2. Allow Controlling Endpoint to Make Dynamic Decisions 140 While an ICE endpoint will assign various priority values to its ICE 141 candidates, these priorities are static and can only be based on a 142 priori knowledge; the shortcomings of this approach are discussed in 143 the first paragraph of Section 2.6 in [RFC5245]. To properly make 144 choices in multi-network and multi-server scenarios, the controlling 145 endpoint MUST be able to make dynamic decisions about the selected 146 candidate pair based on observed network performance. For example, 147 RTT could be used to evaluate which TURN servers to use, as described 148 in [I-D.williams-peer-redirect] To ensure symmetric flows, this 149 implies that the controlling endpoint MUST be able to communicate its 150 choice to the controlled side. 152 3.3. Allow Selected Pair Change At Any Time Without Signaling 154 Expanding on the requirement above, the need to make dynamic 155 decisions is not limited to call setup. A multihomed endpoint may 156 need to switch interfaces based on mobility considerations, or a 157 robust endpoint may want to keep multiple network paths warm and 158 switch immediately if connectivity is interrupted on one of them. As 159 the signaling channel may be affected by the event necessitating the 160 switch, this implies that the controlling endpoint MUST be able to 161 change the selected pair and indicate this to the remote side without 162 signaling. The need for this functionality has been stated in 163 [I-D.wing-mmusic-ice-mobility] and [I-D.singh-avtcore-mprtp]. 165 The rules in [RFC5245] ensure that the controlled endpoint keeps its 166 candidate needed for the selected pair alive. However, in order for 167 alternate pairs to remain available, the controlled endpoint must 168 keep the associated candidates alive as well, following the 169 procedures outlined in [RFC5245], Section 4.1.1.4. This implies that 170 the controlling endpoint MUST have some way to indicate to the 171 controlled side that specific candidates are to be kept alive. 173 3.4. Allow Continuous Addition of Candidates 175 In certain network mobility scenarios, networks may come up and down 176 while the call is active. In order to allow candidates gathered on 177 newly available networks to be used for the selected pair or backup 178 pairs, the endpoint MUST be able to gather candidates on these 179 networks and communicate them to the remote side. While this could 180 be done using an ICE restart, as described in [RFC5245], Section 9.1, 181 the ICE restart may have unintended consequences, such as causing the 182 remote side to regather all candidates. Instead, it would be best if 183 the new candidates could be trickled, as discussed in 184 [I-D.ietf-mmusic-trickle-ice], but even after ICE processing has 185 completed. 187 3.5. Maintain Backwards Compatibility 189 To prevent interoperability problems, ICE endpoints that support the 190 functionality listed above MUST still maintain [RFC5245] compliance 191 when interacting with existing endpoints. However, the ideal 192 solution SHOULD allow some improvements to occur when only the 193 controlling side supports the new functionality. 195 3.6. Minimize Complexity Increase 197 Increased functionality typically leads to increased complexity, 198 which leads to more edge cases, and more implementation bugs. This 199 suggests that in addition to proposing new ICE functionality, the 200 ideal solution SHOULD deprecate superfluous functionality. 202 4. Deprecating Aggressive Nomination 204 4.1. Overview 206 The main benefits of Regular Nomination are that the controlling side 207 can dynamically choose which candidate pair to use, and a clear 208 signal when the nomination process has completed, via the presence of 209 the USE-CANDIDATE flag in a Binding Request. The main benefit of 210 Aggressive Nomination is that it is only necessary to send a single 211 Binding Request before starting the transmission of media, reducing 212 setup latency. Why don't we have both? 214 By preserving the dynamic behavior of Regular Nomination, but 215 allowing media transmission to start upon a single successful 216 connectivity check, as in Aggressive Nomination, the requirements of 217 Section 3.1 and Section 3.2 can be met, while meeting the 218 compatibility requirement from Section 3.5 and, since Aggressive 219 Nomination is no longer needed, the complexity requirement from 220 Section 3.6. 222 4.2. Operation 224 Since media may be transmitted as soon as all components have a valid 225 pair, as indicated in [RFC5245], Page 69, an ICE Agent can begin 226 transmitting media as soon as this occurs, even if it has not sent a 227 Binding Request with USE-CANDIDATE. 229 This pair can change as more pairs are added to the Valid list on the 230 controlling side. When nomination completes, and a final pair is 231 selected, this is communicated to the controlled side via the typical 232 Binding Request with USE-CANDIDATE. 234 On the controlled side, the same process can occur, with the ICE 235 Agent transmitting media as soon as a valid pair exists. To 236 encourage use of symmetric RTP, the controlled ICE Agent SHOULD use 237 the same candidate pair on which it received media from the 238 controlling side. [Doesn't need to be secure media, since the 239 controlling side will finalize this preference through USE-CANDIDATE 240 shortly.] 242 As this is legal ICE behavior, no negotiation of this mechanism 243 should be needed. In the event the receiver drops any packets that 244 arrive before a Binding Request with USE-CANDIDATE set, this will 245 simply lead to brief media clipping and will resolve itself once 246 nomination completes. 248 4.3. Backwards Compatibility 250 When acting in the controlled role, new implementations MUST NOT use 251 Aggressive Nomination. 253 When acting in the controlled role, and the controlling side is using 254 Aggressive Nomination (e.g. sending USE-CANDIDATE in its initial 255 Binding Requests), the standard PRIORITY-based mechanism outlined in 256 [RFC5245], Section 8.1.1.2 should be used to determine the reverse 257 media path. 259 Note that if implementations would prefer to just avoid Aggressive 260 Nomination altogether, they MAY indicate some TBD pseudo-option in 261 the ice-options attribute. Because compliant implementations MUST 262 NOT use Aggressive Nomination if an unknown ICE option is 263 encountered, this effectively prohibits the use of Aggressive 264 Nomination. [N.B. this could be the ice-options:continuous option 265 described below] 267 4.4. Examples 269 An example call setup using Regular Nomination as described above is 270 shown here. Alice is in the controlling role, and Bob is in the 271 controlled role; Alice has a single host candidate and Bob has both 272 host and relay candidates. 274 Alice's initial check to Bob's host candidate fails, but the check to 275 his relay candidate succeeds, so Alice starts transmitting media on 276 her host-relay pair. Bob's initial check from his host candidate to 277 Alice's host candidate succeeds, so he starts transmitting media over 278 this host-host pair to Alice. However, when Alice's host check is 279 later retransmitted, it succeeds, and Alice determines that the host- 280 host pair has a better RTT than the host-relay pair, so she cuts 281 media over to use the host-host pair. Eventually, Alice concludes 282 Regular Nomination by sending a final check to Bob with the USE- 283 CANDIDATE flag set. If Bob had selected a different pair to use than 284 Alice, this action would have forced Bob to use the same pair. 286 Alice Network Bob 287 |(1) STUN Req (Bob host) | | 288 |---------------------------------------------------------->| 289 |(2) STUN Res (Bob host) | | 290 | Lost|<----------------------------| 291 |(3) STUN Req (Bob relay) | | 292 |---------------------------------------------------------->| 293 |(4) STUN Res (Bob relay) | | 294 |<----------------------------------------------------------| 295 |(5) RTP starts (Bob relay) | | 296 |==========================================================>| 297 |(6) STUN Req (Alice host) | | 298 |<----------------------------------------------------------| 299 |(7) STUN Res (Alice host) | | 300 |---------------------------------------------------------->| 301 |(8) RTP starts (Alice host) | | 302 |<==========================================================| 303 |(9) STUN Req (Bob host) | | 304 |---------------------------------------------------------->| 305 |(10) STUN Req (Bob host) | | 306 |<----------------------------------------------------------| 307 |(11) RTP switch (Bob host) | | 308 |==========================================================>| 309 |(12) STUN Req (Bob host, U-C)| | 310 |---------------------------------------------------------->| 311 |(13) STUN Res (Bob host) | | 312 |<----------------------------------------------------------| 314 5. Introducing Continuous Nomination 316 5.1. Overview 318 As discussed above, in mobile environments there can be multiple 319 possible valid candidate pairs, and these can change at various 320 points in the call, as new interfaces go up and down, signal strength 321 for wireless interfaces changes, and new relay servers are 322 discovered. 324 However, under 5245 rules, once a candidate pair is selected and 325 confirmed, via USE-CANDIDATE, nomination has completed and cannot be 326 restarted without performing an ICE restart. This is overly complex 327 in many cases, and especially problematic in some specific ones, 328 namely a wifi-cellular handover, where the signaling path for 329 communicating an ICE restart may be impacted by the handover. 331 To address this situation, this section introduces the concept of 332 "continuous nomination", where the controlling ICE endpoint can 333 adjust the selected candidate pair at any time. By allowing ICE 334 processing to occur continuously during a call, rather than just at 335 call setup, the requirements expressed in Section 3.3 and Section 3.4 336 can be met. 338 5.2. Operation 340 Under continuous nomination, ICE never concludes; new candidates can 341 always be trickled, and a new candidate pair can be selected by the 342 controlling side at any time. 344 When selecting a new candidate pair, the controlling side informs the 345 controlled side of the chosen path by sending a new Binding Request 346 with a USE-CANDIDATE attribute. The decision about which candidate 347 pair to use is fully dynamic; the controlling side can use metrics 348 such as RTT or loss rate to change the selected pair at any time. If 349 Binding Requests need to be sent for any other reason, such as 350 consent checks [I-D.ietf-rtcweb-stun-consent-freshness], any checks 351 sent on the selected pair MUST include a USE-CANDIDATE attribute. 353 Upon receipt of a Binding Request with USE-CANDIDATE, the controlled 354 side MUST switch its media path to the candidate pair on which the 355 Binding Request was received. 357 During continuous nomination, the controlling side may still elect to 358 prune certain candidate pairs; for example, an implementation may 359 choose to drop relay candidates once a successful connection has been 360 established. The controlled side, however, should follow the 361 controlling side's lead in terms of deciding whether any pairs should 362 be pruned. [TODO: should the controlled side have any say in the 363 matter, e.g. to eliminate certain candidates?] The controlling ICE 364 Agent informs the remote side of its preferences by continuing to 365 send Binding Requests to the remote side on each candidate pair that 366 it wants to retain. The controlled ICE Agent SHOULD prune any 367 candidate pairs that have not received a Binding Request in N seconds 368 (30?), and SHOULD NOT keep alive any candidates that are not 369 associated with a live candidate pair. [TODO: decide if this 370 implicit timeout approach is correct, or if we should have some sort 371 of approach similar to TURN LIFETIME indicating when a pair should be 372 GCed, with LIFETIME==0 indicating immediate GC.] One side benefit of 373 doing this is that the continuous exchange of Binding Requests across 374 all candidate pairs allows the RTT and loss rate for each to be 375 reliably determined and kept up to date. 377 If the endpoints have negotiated Trickle ICE support 378 [I-D.ietf-mmusic-trickle-ice], and new candidates become available on 379 either side, the endpoint may send these candidates to the remote 380 side using the existing Trickle ICE mechanisms. Once all of the new 381 candidates have been transmitted, the endpoint MUST send an end-of- 382 candidates messages, which indicates that no more candidates will be 383 sent in the near future. 385 At any point, either side may perform an ICE restart, which will 386 result in both sides gathering new ICE candidates, starting a new 387 continuous nomination sequence, and upon successful completion, 388 discarding all candidates from the previous nomination sequence. 390 5.3. Backwards Compatibility 392 Since standard ICE implementations may not expect the selected pair 393 to change after a USE-CANDIDATE attribute is received, support for 394 continuous nomination is explicitly indicated via a new "continuous" 395 value for ice-options. If the remote side does not support the 396 "continuous" option, the controlling side MUST fall back to Regular 397 Nomination, as specified in [RFC5245], Sectiom 8.1.1. 399 5.4. Examples 401 5.4.1. Switching Between Pairs Based on RTT 403 Alice and Bob have set up a call using ICE and have established 404 multiple valid pairs. The currently selected pair is for a peer-to- 405 peer route, as it had the highest initial priority value. However, 406 they have also kept alive a selected pair that goes through their 407 TURN servers. At a certain point, Alice detects, via the 408 connectivity checks that she continues to do on the relayed pair, 409 that it actually has a better RTT than the peer-to-peer path. She 410 then decides to switch media over to this path. 412 As mentioned above, this is easily handled by Alice immediately 413 switching her media to the relayed path; future STUN checks on this 414 path also include the USE-CANDIDATE attribute. 416 5.4.2. Switching To A New TURN Server 418 Alice and Bob have set up a call using ICE, and are currently sending 419 their media through Alice's TURN server. At a certain point, Alice's 420 application discovers a new TURN server that it thinks might provide 421 a better path for this call. 423 Alice gathers new candidates from this TURN server, and trickles them 424 to Bob. They perform connectivity checks using these candidates, and 425 Alice determines that the RTT when going through this TURN server is 426 better than the RTT of the current relayed path. 428 As in the previous example, this is easily handled by Alice switching 429 media to the new path, along with sending USE-CANDIDATE. If the old 430 path is no longer needed, Alice can destroy the allocation on the old 431 TURN server, and Bob will stop checking it when it stops working. 433 5.4.3. Switching From WLAN to WWAN 435 Alice and Bob have set up a call using ICE, and are currently 436 exchanging their media directly via a peer-to-peer path. Alice is on 437 a mobile device, with both wifi and cellular interfaces, but for 438 power reasons, candidates have only been gathered on the wifi 439 interface. At a certain point, Alice leaves her home while the call 440 is active. 442 In response to the decreasing wifi signal strength, Alice starts to 443 collect candidates on the cellular interface, and trickles them to 444 Bob. They perform connectivity checks using these candidates, and, 445 because of the low wifi signal strength, these candidates are 446 preferred over the existing selected pair. 448 As in the previous examples, Alice can easily switch media to the new 449 selected pair. When Alice walks completely out of wifi range, and 450 the wifi interface goes down, the wifi candidates are pruned, and any 451 valid pairs on Bob's side that use those candidates will time out and 452 be pruned as well. 454 6. Security Considerations 456 TODO 458 7. IANA Considerations 460 A new ICE option "continuous" has been [will be] registered in the 461 "ICE Options" registry created by [RFC6336]. 463 8. Acknowledgements 465 Several people provided significant input into this document, 466 including Martin Thomson, Brandon Williams, and Dan Wing. Emil Ivov 467 also provided several of the examples for continuous nomination. 469 9. References 471 9.1. Normative References 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, March 1997. 476 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 477 (ICE): A Protocol for Network Address Translator (NAT) 478 Traversal for Offer/Answer Protocols", RFC 5245, April 479 2010. 481 [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for 482 Interactive Connectivity Establishment (ICE) Options", RFC 483 6336, July 2011. 485 9.2. Informative References 487 [I-D.ietf-mmusic-trickle-ice] 488 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 489 Incremental Provisioning of Candidates for the Interactive 490 Connectivity Establishment (ICE) Protocol", draft-ietf- 491 mmusic-trickle-ice-02 (work in progress), January 2015. 493 [I-D.ietf-rtcweb-stun-consent-freshness] 494 Perumal, M., Wing, D., R, R., Reddy, T., and M. Thomson, 495 "STUN Usage for Consent Freshness", draft-ietf-rtcweb- 496 stun-consent-freshness-11 (work in progress), December 497 2014. 499 [I-D.singh-avtcore-mprtp] 500 Singh, V., Karkkainen, T., Ott, J., Ahsan, S., and L. 501 Eggert, "Multipath RTP (MPRTP)", draft-singh-avtcore- 502 mprtp-10 (work in progress), November 2014. 504 [I-D.williams-peer-redirect] 505 Williams, B. and T. Reddy, "Peer-specific Redirection for 506 Traversal Using Relays around NAT (TURN)", draft-williams- 507 peer-redirect-03 (work in progress), December 2014. 509 [I-D.wing-mmusic-ice-mobility] 510 Wing, D., Reddy, T., Patil, P., and P. Martinsen, 511 "Mobility with ICE (MICE)", draft-wing-mmusic-ice- 512 mobility-07 (work in progress), June 2014. 514 Appendix A. Change log 516 Changes in draft -00: 518 o Initial version, from mailing list discussion post-IETF 90. 520 Authors' Addresses 522 Justin Uberti 523 Google 524 747 6th Ave S 525 Kirkland, WA 98033 526 USA 528 Email: justin@uberti.name 530 Jonathan Lennox 531 Vidyo 532 433 Hackensack Avenue 533 Hackensack, NJ 07601 534 USA 536 Email: jonathan@vidyo.com