Internet DRAFT - draft-ivov-mmusic-ice-updates
draft-ivov-mmusic-ice-updates
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:
<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>
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",
<http://www.ietf.org/mail-archive/web/mmusic/current/
threads.html#13607>.
[MPICE] Uberti, J. and J. Lennox, "Improving ICE's Nomination
Procedures", <https://docs.google.com/document/
d/1P1XPCRJKBkSjwCzIIEUJmp7V694_FzJQe-fvN8bk-Xw/edit>.
[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]
