[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                          J. Uberti
Internet-Draft                                                    Google
Intended status: Standards Track                               J. Lennox
Expires: September 10, 2015                                        Vidyo
                                                          March 09, 2015

                Improvements to ICE Candidate Nomination


   This document makes recommendations for simplifying and improving the
   procedures for candidate nomination in Interactive Connectivity
   Establishment (ICE).

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 September 10, 2015.

Copyright Notice

   Copyright (c) 2015 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.

Uberti & Lennox        Expires September 10, 2015               [Page 1]

Internet-Draft                   IceNom                       March 2015

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Goals and Requirements  . . . . . . . . . . . . . . . . . . .   3
     3.1.  Minimize Call Setup Latency . . . . . . . . . . . . . . .   3
     3.2.  Allow Controlling Endpoint to Make Dynamic Decisions  . .   3
     3.3.  Allow Selected Pair Change At Any Time Without Signaling    4
     3.4.  Allow Continuous Addition of Candidates . . . . . . . . .   4
     3.5.  Maintain Backwards Compatibility  . . . . . . . . . . . .   4
     3.6.  Minimize Complexity Increase  . . . . . . . . . . . . . .   5
   4.  Deprecating Aggressive Nomination . . . . . . . . . . . . . .   5
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Operation . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Backwards Compatibility . . . . . . . . . . . . . . . . .   6
     4.4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Introducing Continuous Nomination . . . . . . . . . . . . . .   7
     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Operation . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.3.  Backwards Compatibility . . . . . . . . . . . . . . . . .   9
     5.4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   9
       5.4.1.  Switching Between Pairs Based on RTT  . . . . . . . .   9
       5.4.2.  Switching To A New TURN Server  . . . . . . . . . . .   9
       5.4.3.  Switching From WLAN to WWAN . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  Change log . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Interactive Connectivity Establishment (ICE) attempts to find the
   'best' path for connectivity between two peers; in ICE parlance,
   these paths are known as 'candidate pairs'.  During the ICE process,
   one endpoint, known as the 'controlling' endpoint, selects a
   candidate pair as the best pair; this action is known as nomination.
   ICE supports two different mechanisms for performing nomination,
   known as Regular Nomination, and Aggressive Nomination.

   However, each of these modes have flaws that restrict their
   usefulness.  Regular Nomination, as currently speced, requires a best
   pair to be chosen before media transmission can start, causing
   unnecessary call setup delay.  Aggressive Nomination, while avoiding
   this delay, gives the controlling endpoint much less discretion into

Uberti & Lennox        Expires September 10, 2015               [Page 2]

Internet-Draft                   IceNom                       March 2015

   which candidate pair is chosen, preventing it from making decisions
   based on dynamic factors such as RTT or loss rate.  Needless to say,
   the presence of both modes also adds nontrivial complexity.

   Lastly, ICE is currently defined as a finite process, where the
   decision on the optimal candidate pair is made during call setup and
   infrequently (if ever) changed.  While this may be acceptable for
   endpoints with static network configurations, it fails to meet the
   needs of mobile endpoints, who may need to seamlessly move between
   networks, or be connected to multiple networks simultaneously.  In
   these cases, the controlling endpoint may want to maintain multiple
   potential candidate pairs, and make dynamic decisions to switch
   between them as conditions change.

   To address these challenges, this document makes two proposals for
   refactoring ICE nomination - merging Regular and Aggressive
   Nomination, and introducing a new mode, known as Continuous
   Nomination.  This makes ICE substantially more flexible without
   increasing complexity.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

3.  Goals and Requirements

   The goals for improved ICE nomination are enumerated below.

3.1.  Minimize Call Setup Latency

   Modern ICE agents will often have multiple network interfaces and
   multiple servers from which to obtain ICE candidates.  While some ICE
   checks may succeed quickly, finishing the entire set of checks can
   easily take multiple seconds; this concern is discussed in [RFC5245],
   Section  As a result, ICE endpoints MUST be able to start
   transmitting media immediately upon a successful ICE check, and MUST
   retain the ability to switch if a better candidate pair becomes
   available later.

3.2.  Allow Controlling Endpoint to Make Dynamic Decisions

   While an ICE endpoint will assign various priority values to its ICE
   candidates, these priorities are static and can only be based on a
   priori knowledge; the shortcomings of this approach are discussed in
   the first paragraph of Section 2.6 in [RFC5245].  To properly make
   choices in multi-network and multi-server scenarios, the controlling

Uberti & Lennox        Expires September 10, 2015               [Page 3]

Internet-Draft                   IceNom                       March 2015

   endpoint MUST be able to make dynamic decisions about the selected
   candidate pair based on observed network performance.  For example,
   RTT could be used to evaluate which TURN servers to use, as described
   in [I-D.williams-peer-redirect] To ensure symmetric flows, this
   implies that the controlling endpoint MUST be able to communicate its
   choice to the controlled side.

3.3.  Allow Selected Pair Change At Any Time Without Signaling

   Expanding on the requirement above, the need to make dynamic
   decisions is not limited to call setup.  A multihomed endpoint may
   need to switch interfaces based on mobility considerations, or a
   robust endpoint may want to keep multiple network paths warm and
   switch immediately if connectivity is interrupted on one of them.  As
   the signaling channel may be affected by the event necessitating the
   switch, this implies that the controlling endpoint MUST be able to
   change the selected pair and indicate this to the remote side without
   signaling.  The need for this functionality has been stated in
   [I-D.wing-mmusic-ice-mobility] and [I-D.singh-avtcore-mprtp].

   The rules in [RFC5245] ensure that the controlled endpoint keeps its
   candidate needed for the selected pair alive.  However, in order for
   alternate pairs to remain available, the controlled endpoint must
   keep the associated candidates alive as well, following the
   procedures outlined in [RFC5245], Section  This implies that
   the controlling endpoint MUST have some way to indicate to the
   controlled side that specific candidates are to be kept alive.

3.4.  Allow Continuous Addition of Candidates

   In certain network mobility scenarios, networks may come up and down
   while the call is active.  In order to allow candidates gathered on
   newly available networks to be used for the selected pair or backup
   pairs, the endpoint MUST be able to gather candidates on these
   networks and communicate them to the remote side.  While this could
   be done using an ICE restart, as described in [RFC5245], Section 9.1,
   the ICE restart may have unintended consequences, such as causing the
   remote side to regather all candidates.  Instead, it would be best if
   the new candidates could be trickled, as discussed in
   [I-D.ietf-mmusic-trickle-ice], but even after ICE processing has

3.5.  Maintain Backwards Compatibility

   To prevent interoperability problems, ICE endpoints that support the
   functionality listed above MUST still maintain [RFC5245] compliance
   when interacting with existing endpoints.  However, the ideal

Uberti & Lennox        Expires September 10, 2015               [Page 4]

Internet-Draft                   IceNom                       March 2015

   solution SHOULD allow some improvements to occur when only the
   controlling side supports the new functionality.

3.6.  Minimize Complexity Increase

   Increased functionality typically leads to increased complexity,
   which leads to more edge cases, and more implementation bugs.  This
   suggests that in addition to proposing new ICE functionality, the
   ideal solution SHOULD deprecate superfluous functionality.

4.  Deprecating Aggressive Nomination

4.1.  Overview

   The main benefits of Regular Nomination are that the controlling side
   can dynamically choose which candidate pair to use, and a clear
   signal when the nomination process has completed, via the presence of
   the USE-CANDIDATE flag in a Binding Request.  The main benefit of
   Aggressive Nomination is that it is only necessary to send a single
   Binding Request before starting the transmission of media, reducing
   setup latency.  Why don't we have both?

   By preserving the dynamic behavior of Regular Nomination, but
   allowing media transmission to start upon a single successful
   connectivity check, as in Aggressive Nomination, the requirements of
   Section 3.1 and Section 3.2 can be met, while meeting the
   compatibility requirement from Section 3.5 and, since Aggressive
   Nomination is no longer needed, the complexity requirement from
   Section 3.6.

4.2.  Operation

   Since media may be transmitted as soon as all components have a valid
   pair, as indicated in [RFC5245], Page 69, an ICE Agent can begin
   transmitting media as soon as this occurs, even if it has not sent a
   Binding Request with USE-CANDIDATE.

   This pair can change as more pairs are added to the Valid list on the
   controlling side.  When nomination completes, and a final pair is
   selected, this is communicated to the controlled side via the typical
   Binding Request with USE-CANDIDATE.

   On the controlled side, the same process can occur, with the ICE
   Agent transmitting media as soon as a valid pair exists.  To
   encourage use of symmetric RTP, the controlled ICE Agent SHOULD use
   the same candidate pair on which it received media from the
   controlling side.  [Doesn't need to be secure media, since the

Uberti & Lennox        Expires September 10, 2015               [Page 5]

Internet-Draft                   IceNom                       March 2015

   controlling side will finalize this preference through USE-CANDIDATE

   As this is legal ICE behavior, no negotiation of this mechanism
   should be needed.  In the event the receiver drops any packets that
   arrive before a Binding Request with USE-CANDIDATE set, this will
   simply lead to brief media clipping and will resolve itself once
   nomination completes.

4.3.  Backwards Compatibility

   When acting in the controlled role, new implementations MUST NOT use
   Aggressive Nomination.

   When acting in the controlled role, and the controlling side is using
   Aggressive Nomination (e.g. sending USE-CANDIDATE in its initial
   Binding Requests), the standard PRIORITY-based mechanism outlined in
   [RFC5245], Section should be used to determine the reverse
   media path.

   Note that if implementations would prefer to just avoid Aggressive
   Nomination altogether, they MAY indicate some TBD pseudo-option in
   the ice-options attribute.  Because compliant implementations MUST
   NOT use Aggressive Nomination if an unknown ICE option is
   encountered, this effectively prohibits the use of Aggressive
   Nomination.  [N.B. this could be the ice-options:continuous option
   described below]

4.4.  Examples

   An example call setup using Regular Nomination as described above is
   shown here.  Alice is in the controlling role, and Bob is in the
   controlled role; Alice has a single host candidate and Bob has both
   host and relay candidates.

   Alice's initial check to Bob's host candidate fails, but the check to
   his relay candidate succeeds, so Alice starts transmitting media on
   her host-relay pair.  Bob's initial check from his host candidate to
   Alice's host candidate succeeds, so he starts transmitting media over
   this host-host pair to Alice.  However, when Alice's host check is
   later retransmitted, it succeeds, and Alice determines that the host-
   host pair has a better RTT than the host-relay pair, so she cuts
   media over to use the host-host pair.  Eventually, Alice concludes
   Regular Nomination by sending a final check to Bob with the USE-
   CANDIDATE flag set.  If Bob had selected a different pair to use than
   Alice, this action would have forced Bob to use the same pair.

Uberti & Lennox        Expires September 10, 2015               [Page 6]

Internet-Draft                   IceNom                       March 2015

    Alice                        Network                         Bob
      |(1) STUN Req (Bob host)      |                             |
      |(2) STUN Res (Bob host)      |                             |
      |                         Lost|<----------------------------|
      |(3) STUN Req (Bob relay)     |                             |
      |(4) STUN Res (Bob relay)     |                             |
      |(5) RTP starts (Bob relay)   |                             |
      |(6) STUN Req (Alice host)    |                             |
      |(7) STUN Res (Alice host)    |                             |
      |(8) RTP starts (Alice host)  |                             |
      |(9) STUN Req (Bob host)      |                             |
      |(10) STUN Req (Bob host)     |                             |
      |(11) RTP switch (Bob host)   |                             |
      |(12) STUN Req (Bob host, U-C)|                             |
      |(13) STUN Res (Bob host)     |                             |

5.  Introducing Continuous Nomination

5.1.  Overview

   As discussed above, in mobile environments there can be multiple
   possible valid candidate pairs, and these can change at various
   points in the call, as new interfaces go up and down, signal strength
   for wireless interfaces changes, and new relay servers are

   However, under 5245 rules, once a candidate pair is selected and
   confirmed, via USE-CANDIDATE, nomination has completed and cannot be
   restarted without performing an ICE restart.  This is overly complex
   in many cases, and especially problematic in some specific ones,
   namely a wifi-cellular handover, where the signaling path for
   communicating an ICE restart may be impacted by the handover.

   To address this situation, this section introduces the concept of
   "continuous nomination", where the controlling ICE endpoint can
   adjust the selected candidate pair at any time.  By allowing ICE

Uberti & Lennox        Expires September 10, 2015               [Page 7]

Internet-Draft                   IceNom                       March 2015

   processing to occur continuously during a call, rather than just at
   call setup, the requirements expressed in Section 3.3 and Section 3.4
   can be met.

5.2.  Operation

   Under continuous nomination, ICE never concludes; new candidates can
   always be trickled, and a new candidate pair can be selected by the
   controlling side at any time.

   When selecting a new candidate pair, the controlling side informs the
   controlled side of the chosen path by sending a new Binding Request
   with a USE-CANDIDATE attribute.  The decision about which candidate
   pair to use is fully dynamic; the controlling side can use metrics
   such as RTT or loss rate to change the selected pair at any time.  If
   Binding Requests need to be sent for any other reason, such as
   consent checks [I-D.ietf-rtcweb-stun-consent-freshness], any checks
   sent on the selected pair MUST include a USE-CANDIDATE attribute.

   Upon receipt of a Binding Request with USE-CANDIDATE, the controlled
   side MUST switch its media path to the candidate pair on which the
   Binding Request was received.

   During continuous nomination, the controlling side may still elect to
   prune certain candidate pairs; for example, an implementation may
   choose to drop relay candidates once a successful connection has been
   established.  The controlled side, however, should follow the
   controlling side's lead in terms of deciding whether any pairs should
   be pruned.  [TODO: should the controlled side have any say in the
   matter, e.g. to eliminate certain candidates?]  The controlling ICE
   Agent informs the remote side of its preferences by continuing to
   send Binding Requests to the remote side on each candidate pair that
   it wants to retain.  The controlled ICE Agent SHOULD prune any
   candidate pairs that have not received a Binding Request in N seconds
   (30?), and SHOULD NOT keep alive any candidates that are not
   associated with a live candidate pair.  [TODO: decide if this
   implicit timeout approach is correct, or if we should have some sort
   of approach similar to TURN LIFETIME indicating when a pair should be
   GCed, with LIFETIME==0 indicating immediate GC.]  One side benefit of
   doing this is that the continuous exchange of Binding Requests across
   all candidate pairs allows the RTT and loss rate for each to be
   reliably determined and kept up to date.

   If the endpoints have negotiated Trickle ICE support
   [I-D.ietf-mmusic-trickle-ice], and new candidates become available on
   either side, the endpoint may send these candidates to the remote
   side using the existing Trickle ICE mechanisms.  Once all of the new
   candidates have been transmitted, the endpoint MUST send an end-of-

Uberti & Lennox        Expires September 10, 2015               [Page 8]

Internet-Draft                   IceNom                       March 2015

   candidates messages, which indicates that no more candidates will be
   sent in the near future.

   At any point, either side may perform an ICE restart, which will
   result in both sides gathering new ICE candidates, starting a new
   continuous nomination sequence, and upon successful completion,
   discarding all candidates from the previous nomination sequence.

5.3.  Backwards Compatibility

   Since standard ICE implementations may not expect the selected pair
   to change after a USE-CANDIDATE attribute is received, support for
   continuous nomination is explicitly indicated via a new "continuous"
   value for ice-options.  If the remote side does not support the
   "continuous" option, the controlling side MUST fall back to Regular
   Nomination, as specified in [RFC5245], Sectiom 8.1.1.

5.4.  Examples

5.4.1.  Switching Between Pairs Based on RTT

   Alice and Bob have set up a call using ICE and have established
   multiple valid pairs.  The currently selected pair is for a peer-to-
   peer route, as it had the highest initial priority value.  However,
   they have also kept alive a selected pair that goes through their
   TURN servers.  At a certain point, Alice detects, via the
   connectivity checks that she continues to do on the relayed pair,
   that it actually has a better RTT than the peer-to-peer path.  She
   then decides to switch media over to this path.

   As mentioned above, this is easily handled by Alice immediately
   switching her media to the relayed path; future STUN checks on this
   path also include the USE-CANDIDATE attribute.

5.4.2.  Switching To A New TURN Server

   Alice and Bob have set up a call using ICE, and are currently sending
   their media through Alice's TURN server.  At a certain point, Alice's
   application discovers a new TURN server that it thinks might provide
   a better path for this call.

   Alice gathers new candidates from this TURN server, and trickles them
   to Bob. They perform connectivity checks using these candidates, and
   Alice determines that the RTT when going through this TURN server is
   better than the RTT of the current relayed path.

   As in the previous example, this is easily handled by Alice switching
   media to the new path, along with sending USE-CANDIDATE.  If the old

Uberti & Lennox        Expires September 10, 2015               [Page 9]

Internet-Draft                   IceNom                       March 2015

   path is no longer needed, Alice can destroy the allocation on the old
   TURN server, and Bob will stop checking it when it stops working.

5.4.3.  Switching From WLAN to WWAN

   Alice and Bob have set up a call using ICE, and are currently
   exchanging their media directly via a peer-to-peer path.  Alice is on
   a mobile device, with both wifi and cellular interfaces, but for
   power reasons, candidates have only been gathered on the wifi
   interface.  At a certain point, Alice leaves her home while the call
   is active.

   In response to the decreasing wifi signal strength, Alice starts to
   collect candidates on the cellular interface, and trickles them to
   Bob. They perform connectivity checks using these candidates, and,
   because of the low wifi signal strength, these candidates are
   preferred over the existing selected pair.

   As in the previous examples, Alice can easily switch media to the new
   selected pair.  When Alice walks completely out of wifi range, and
   the wifi interface goes down, the wifi candidates are pruned, and any
   valid pairs on Bob's side that use those candidates will time out and
   be pruned as well.

6.  Security Considerations


7.  IANA Considerations

   A new ICE option "continuous" has been [will be] registered in the
   "ICE Options" registry created by [RFC6336].

8.  Acknowledgements

   Several people provided significant input into this document,
   including Martin Thomson, Brandon Williams, and Dan Wing.  Emil Ivov
   also provided several of the examples for continuous nomination.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Uberti & Lennox        Expires September 10, 2015              [Page 10]

Internet-Draft                   IceNom                       March 2015

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245, April

   [RFC6336]  Westerlund, M. and C. Perkins, "IANA Registry for
              Interactive Connectivity Establishment (ICE) Options", RFC
              6336, July 2011.

9.2.  Informative References

              Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
              Incremental Provisioning of Candidates for the Interactive
              Connectivity Establishment (ICE) Protocol", draft-ietf-
              mmusic-trickle-ice-02 (work in progress), January 2015.

              Perumal, M., Wing, D., R, R., Reddy, T., and M. Thomson,
              "STUN Usage for Consent Freshness", draft-ietf-rtcweb-
              stun-consent-freshness-11 (work in progress), December

              Singh, V., Karkkainen, T., Ott, J., Ahsan, S., and L.
              Eggert, "Multipath RTP (MPRTP)", draft-singh-avtcore-
              mprtp-10 (work in progress), November 2014.

              Williams, B. and T. Reddy, "Peer-specific Redirection for
              Traversal Using Relays around NAT (TURN)", draft-williams-
              peer-redirect-03 (work in progress), December 2014.

              Wing, D., Reddy, T., Patil, P., and P. Martinsen,
              "Mobility with ICE (MICE)", draft-wing-mmusic-ice-
              mobility-07 (work in progress), June 2014.

Appendix A.  Change log

   Changes in draft -00:

   o  Initial version, from mailing list discussion post-IETF 90.

Uberti & Lennox        Expires September 10, 2015              [Page 11]

Internet-Draft                   IceNom                       March 2015

Authors' Addresses

   Justin Uberti
   747 6th Ave S
   Kirkland, WA  98033

   Email: justin@uberti.name

   Jonathan Lennox
   433 Hackensack Avenue
   Hackensack, NJ  07601

   Email: jonathan@vidyo.com

Uberti & Lennox        Expires September 10, 2015              [Page 12]