| Network Working Group | E. Ivov |
| Internet-Draft | Jitsi |
| Intended status: Standards Track | November 10, 2014 |
| Expires: May 14, 2015 |
Non-disruptive Candidate Updates for the Interactive Connectivity Establishment (ICE) Protocol
draft-ivov-mmusic-ice-updates-00
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.
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 14, 2015.
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.
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.
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 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.
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.
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:
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:
<iq from='romeo@montague.lit/orchard'
id='pd81b49s'
to='juliet@capulet.lit/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='transport-info'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='this-is-the-audio-content'>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
pwd='asd88fgpdd777uzjYhagZg'
ufrag='8hhy'>
</transport>
</content>
</jingle>
</iq>
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.
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 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.
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.
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:
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.
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.
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:
In the same time 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.
TBD