Network Working Group E. Ivov Internet-Draft Jitsi Intended status: Standards Track November 9, 2014 Expires: May 13, 2015 Non-disruptive Candidate Updates for the Interactive Connectivity Establishment (ICE) Protocol draft-ivov-mmusic-ice-updates-00 Abstract This document describes a mechanism for updating the transport parameters of real-time communication sessions (e.g. as a result of mid-session device mobility) without disrupting ongoing communication and without requiring Offer/Answer negotiation. Status of This Memo 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 May 13, 2015. Copyright Notice Copyright (c) 2014 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. Ivov Expires May 13, 2015 [Page 1] Internet-Draft ICE Updates November 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Multipath ICE . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Triggering a Trickle ICE Restart . . . . . . . . . . . . . . 3 3.1. Trickle-triggering an ICE restart . . . . . . . . . . . . 3 3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Re-checking currently valid pairs . . . . . . . . . . 4 3.2.2. Relationship with Multipath ICE . . . . . . . . . . . 5 4. The case against infinite trickling . . . . . . . . . . . . . 5 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Switching to a better interface. No ICE restart. . . . . 6 5.2. Adding an interface. ICE restart required . . . . . . . . 6 5.3. Scenarios involving MICE . . . . . . . . . . . . . . . . 7 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The Interactive Connectivity Establishment (ICE) protocol [RFC5245] defines a way of discovering and validating a path between two peers. Switching an ongoing media session to an alternative path is therefore only possible after an ICE restart that would again produce a single "nominated" candidate pair for use by the applications. As a result, implementing path optimizations is currently a cumbersome process that is often implemented in a disruptive way or not supported at all. This document discusses ways of simplifying the process. Special attention is being paid to preserving existing features in ICE and trickle ICE [I-D.ivov-mmusic-trickle-ice] that allow implementations today to promptly release unused candidates or detect failures in a deterministic way. 2. Multipath ICE An ongoing discussion in MMUSIC [ICE-OPTS] is already investigating the possibility of having ICE processing yield multiple usable candidate pairs. A rough proposal for achieving this is being currently fleshed out [MPICE] and an IETF submission would likely follow shortly. Having ICE produce multiple usable candidate pairs opens up possibilities for various application specific adjustments and optimizations. Using multiple routes concurrently [I-D.singh-avtcore-mprtp] is one such example. Being able to swiftly switch between existing routes based on RTT or local Ivov Expires May 13, 2015 [Page 2] Internet-Draft ICE Updates November 2014 indicators (e.g., perceived Wi-Fi signal strength) is another. Rapid route switching can also be used to support network mobility as described in [I-D.wing-mmusic-ice-mobility]. (PENDING: use with MICE requires some further thought in order to optimize the case of a mobile peer talking to a public media server). Being able to update the list of available routes however, is a separate problem that is best handled by reusing of ICE restarts, trickle ICE and slightly improved signalling Section 3. 3. Triggering a Trickle ICE Restart The vanilla ICE specifications [RFC5245] defines ICE restarts as a non disruptive process where media can continue flowing between existing candidates while ICE is being re-run to discover new paths. ICE restarts can be triggered by either party and are signalled with the generation of new ice-ufrag and ice-pwd attributes by the party who is triggering the restart. An ICE restart may result in a set of valid candidate pairs that contains none, some, or all of the candidate pairs being used prior to the restart. The new candidate pair set may obviously also contain zero or more new valid pairs that were not available prior to the restart. It is entirely possible for an ICE restart to complete without triggering even a single change to current media flows. This is important because it gives implementors the possibility to use ICE restart as an incremental process that does not in any way disrupt existing paths. 3.1. Trickle-triggering an ICE restart Vanilla ICE defines trigger for an ICE restart as a change in the ice-ufrag and ice-pwd attributes. While this constitutes a trivial change, standard Offer/Answer semantics imply the generation of a complete offer and answer even if the above to attributes are so far the only change in the session. To avoid such a heavy process, this document suggests using trickle ICE semantics for the delivery of the two attributes. This way, whenever an ICE implementation stack issues the new values for the ice-ufrag and ice-pwd attributes, the using application will deliver them the same way it usually delivers trickled candidates. For example, for the Session Initiation Protocol (SIP) [RFC3261] this would imply sending an SIP INFO request [I-D.ivov-mmusic-trickle-ice-sip] that could look like the following: Ivov Expires May 13, 2015 [Page 3] Internet-Draft ICE Updates November 2014 INFO sip:alice@example.com SIP/2.0 ... Info-Package: trickle-ice Content-type: application/sdp Content-Disposition: Info-Package Content-length: ... a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY In the case of XMPP Jingle [XEP-0176] the ICE restart trigger could look like this: 3.2. Operation Once a restart is triggered, ICE processing will mostly continue similarly to the way it does with initial session establishment. Pairs and checklists will be recreated as per regular trickle ICE procedures. 3.2.1. Re-checking currently valid pairs Depending on the event that triggered the ICE restart, some of the newly formed pairs will likely be identical to those currently in-use by the agents. This would be the case, for example, in situations where a new interface has become available. While it is very likely for these pairs to continue working the same way as before the Ivov Expires May 13, 2015 [Page 4] Internet-Draft ICE Updates November 2014 restart, it is RECOMMENDED that they be subject to a new set of connectivity checks in case the change in network configuration has further impact than the usually expected. For example, a newly available network interface would normally only imply new connection possibilities. In some cases however, such as the launch of a VPN application, the new interface might have been accompanied by a change of routing policies that have invalidated the earlier available routes. 3.2.2. Relationship with Multipath ICE An ICE restart would typically result in a set of valid pairs. In cases where Multipath ICE is being used, agents MUST make sure that, as long as they are still valid, all paths that were in use prior to the restart, would still be usable after it completes. The exact semantics for selecting and enabling one or multiple such paths simultaneously are still being discussed and worked out in [MPICE]. Still, regardless of the specific messaging to take place, it is important that ICE implementations can and should behave in a way that does not, even briefly, disrupt media flow on pairs that are still valid. 4. The case against infinite trickling As part of the ongoing discussions on improving ICE, it has been suggested [MPICE] that candidate updates be handled by making candidate trickling an endless process. While endless trickling does provide a simple solution to some common use cases, it also introduces some significant drawbacks: o Clearly determining failure. In the vast majority of cases, ICE agents would likely have a very finite set of candidates. Trickling and checking these candidates is currently a very clearly delimited process that makes it possible to detect failure and alert users in a timely manner. Using endless trickling would make that impossible and would require the introduction of "magic" timers. o Promptly releasing and reallocating unnecessary candidates. Currently, the finite nature of ICE processing makes it trivial for agents to decide when they need to release, stop maintaining, or reallocate resources such as relay or server-reflexive candidates. Losing the clear boundaries of ICE processing would remove that ability and, once again, require the introduction of arbitrary timers in order to avoid wasting resources. Ivov Expires May 13, 2015 [Page 5] Internet-Draft ICE Updates November 2014 o Endless trickling has been known to hang out with Ronan, the Green Goblin and various zombies. It also regularly contributes to global warming and eats puppies. 5. Examples The following examples try to describe a number of cases that require transport reconfiguration. Some of them might be only a matter of switching between previously validated routes without requiring an ICE restart. Others do trigger a restart without however disrupting existing connectivity. 5.1. Switching to a better interface. No ICE restart. Arya and Bran use the new multipath ICE mechanisms and have a set of pre-validated candidate pairs. They are currently communicating over 4G because, for example, it presented better RTT during ICE processing. At a certain point Arya detects that the consent checks exchanged with Bob over her Wi-Fi interface start presenting a lower RTT. Alternately she could also receive an indication from the OS that the Wi-Fi signal strength detected by her wireless interface has gone above a certain threshold. For either of these reasons Arya wishes to switch media from her 4G to her Wi-Fi interface. This scenario DOES NOT require an ICE restart since no additional checks are necessary. Hopefully such a switch will be natively supported by the new multipath ICE mechanism, for example, through the emission of a USE-CANDIDATE binding request over Arya's Wi-Fi interface. 5.2. Adding an interface. ICE restart required Arianne has an ongoing media session with Brienne over a 4G interface. Brienne on the other hand posesses a wired and a wireless interface. Her connection with Arianne is happening through a VPN interface configured on top of her wireless interface. Arianne's Wi-Fi interface then becomes available and she wishes to migrate her session from 4G to Wi-Fi. In order to do this Arianne does the following: o She triggers an ICE restart by trickling new ice-ufrag and ice-pwd values to Brienne. o She continues exchanging media with Brienne over her 4G interface. Ivov Expires May 13, 2015 [Page 6] Internet-Draft ICE Updates November 2014 o She starts gathering and trickling local host, srflx and relay candidates to Brienne. o She starts receiving trickled candidates from Brienne, she pairs them with her local ones and starts checking them In the same time Brienne: o Continues exchanging media with Arianne. o Re-allocates host and srflx candidates for her wireless and wired interfaces and then trickles them to Brienne. Once a new set of candidates are validated, Arianne and Brienne may decide to migrate their session to the pair containing any of Arianne's new Wi-Fi addresses. 5.3. Scenarios involving MICE TBD 6. Normative References [I-D.ivov-mmusic-trickle-ice] Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", draft-ivov- mmusic-trickle-ice-01 (work in progress), March 2013. [I-D.ivov-mmusic-trickle-ice-sip] Ivov, E., Marocco, E., and C. Holmberg, "A Session Initiation Protocol (SIP) usage for Trickle ICE", draft- ivov-mmusic-trickle-ice-sip-02 (work in progress), June 2014. [I-D.singh-avtcore-mprtp] Singh, V., Karkkainen, T., Ott, J., Ahsan, S., and L. Eggert, "Multipath RTP (MPRTP)", draft-singh-avtcore- mprtp-09 (work in progress), June 2014. [I-D.wing-mmusic-ice-mobility] Wing, D., Reddy, T., Patil, P., and P. Martinsen, "Mobility with ICE (MICE)", draft-wing-mmusic-ice- mobility-07 (work in progress), June 2014. Ivov Expires May 13, 2015 [Page 7] Internet-Draft ICE Updates November 2014 [ICE-OPTS] "MMUSIC Discussion on ICE Optimisations", . [MPICE] Uberti, J. and J. Lennox, "Improving ICE's Nomination Procedures", . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [XEP-0176] Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J., Egan, S., and R. McQueen, "XEP-0176: Jingle ICE-UDP Transport Method", XEP XEP-0176, June 2009. Author's Address Emil Ivov Jitsi Strasbourg 67000 France Phone: +33 6 72 81 15 55 Email: emcho@jitsi.org Ivov Expires May 13, 2015 [Page 8]