draft-uberti-mmusic-nombis.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc5245 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY rfc6336 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6336.xml">
<!ENTITY icemob SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-mmusic-ice-mobility.xml">
<!ENTITY mprtp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.singh-avtcore-mprtp.xml">
<!ENTITY redirect SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.williams-peer-redirect.xml">
<!ENTITY consent SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-stun-consent-freshness.xml">
<!ENTITY trickle SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-trickle-ice.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<?rfc tocdepth="4"?>

<rfc category="std" docName="draft-uberti-mmusic-nombis-00" ipr="trust200902">
  <front>
    <title abbrev="IceNom">Improvements to ICE Candidate Nomination</title>

    <author fullname="Justin Uberti" initials="J." surname="Uberti">
      <organization>Google</organization>

      <address>
        <postal>
          <street>747 6th Ave S</street>

          <city>Kirkland</city>

          <region>WA</region>

          <code>98033</code>

          <country>USA</country>
        </postal>

        <email>justin@uberti.name</email>
      </address>
    </author>

    <author fullname="Jonathan Lennox" initials="J." surname="Lennox">
      <organization>Vidyo</organization>

      <address>
        <postal>
          <street>433 Hackensack Avenue</street>

          <city>Hackensack</city>

          <region>NJ</region>

          <code>07601</code>

          <country>USA</country>
        </postal>

        <email>jonathan@vidyo.com</email>
      </address>
    </author>

    <date day="09" month="March" year="2015" />

    <area>RAI</area>

    <abstract>
      <t>This document makes recommendations for simplifying and improving the
      procedures for candidate nomination in Interactive Connectivity Establishment (ICE).</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>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.</t>
      <t>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 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.</t>
      <t>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.</t>
      <t>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.
      </t>
    </section>

    <section title="Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119"></xref>.</t>
    </section>

    <section title="Goals and Requirements">
      <t>The goals for improved ICE nomination are enumerated below.</t>
      <section title="Minimize Call Setup Latency" anchor="minimize-latency">
          <t>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 <xref target="RFC5245"/>, Section 8.1.1.1.
          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.
          </t>
      </section>
      <section title="Allow Controlling Endpoint to Make Dynamic Decisions" anchor="dynamic-decisions">
          <t>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 <xref target="RFC5245"/>. To
          properly make choices in multi-network and multi-server scenarios, the controlling
          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 <xref target="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.
          </t>
      </section>
       <section title="Allow Selected Pair Change At Any Time Without Signaling" anchor="continuous-change">
          <t>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 <xref target="I-D.wing-mmusic-ice-mobility"/> and
          <xref target="I-D.singh-avtcore-mprtp"/>.
          </t>
          <t>The rules in <xref target="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 <xref target="RFC5245"/>, Section 4.1.1.4. This implies
          that the controlling endpoint MUST have some way to
          indicate to the controlled side that specific candidates are to be kept alive.
          </t>
      </section>
      <section title="Allow Continuous Addition of Candidates" anchor="continuous-candidates">
          <t>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
          <xref target="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 <xref target="I-D.ietf-mmusic-trickle-ice"/>, but even after
          ICE processing has completed.
          </t>
      </section>
      <section title="Maintain Backwards Compatibility" anchor="maintain-backcompat">
          <t>To prevent interoperability problems, ICE endpoints that support the
          functionality listed above MUST still maintain <xref target="RFC5245"/> compliance
          when interacting with existing endpoints. However, the ideal solution SHOULD
          allow some improvements to occur when only the controlling side supports the new
          functionality.</t>
      </section>
      <section title="Minimize Complexity Increase" anchor="minimize-complexity">
          <t>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.</t>
      </section>
    </section>

    <section title="Deprecating Aggressive Nomination">
      <section title="Overview">
        <t>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?
        </t>
        <t>
        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 <xref target="minimize-latency"/>
        and <xref target="dynamic-decisions"/> can be met, while meeting the compatibility
        requirement from <xref target="maintain-backcompat" /> and, since
        Aggressive Nomination is no longer needed, the complexity requirement from
        <xref target="minimize-complexity" />.
        </t>
      </section>
      <section title="Operation">
        <t>Since media may be transmitted as soon as all components have a valid pair,
        as indicated in <xref target="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.</t>
        <t>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.</t>
        <t>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 controlling side will finalize this preference
through USE-CANDIDATE shortly.]</t>
        <t>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.</t>
      </section>
      <section title="Backwards Compatibility">
        <t>When acting in the controlled role, new implementations MUST NOT use
        Aggressive Nomination.</t>
        <t>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 <xref target="RFC5245"/>,
        Section 8.1.1.2 should be used to determine the reverse media path.
        </t>
        <t>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]
        </t>
      </section>
      <section title="Examples">
        <t>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.</t>
        <t>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.
        </t>
        <t><figure><artwork><![CDATA[
 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)     |                             |
   |<----------------------------------------------------------|
]]></artwork></figure></t>
      </section>
    </section>

    <section title="Introducing Continuous Nomination">
      <section title="Overview">
        <t>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 discovered.</t>
        <t>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.</t>
        <t>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 processing to occur continuously during a call, rather than just at call
        setup, the requirements expressed in <xref target="continuous-change"/> and
        <xref target="continuous-candidates"/> can be met.</t>
      </section>
      <section title="Operation">
        <t>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.</t>
        <t>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
        <xref target="I-D.ietf-rtcweb-stun-consent-freshness"/>, any checks sent on
        the selected pair MUST include a USE-CANDIDATE attribute.
        </t>
        <t>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.</t>
        <t>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.</t>
        <t>If the endpoints have negotiated Trickle ICE support
        <xref target="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-candidates
        messages, which indicates that no more candidates will be sent
        in the near future. </t>
        <t>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.</t>
      </section>
      <section title="Backwards Compatibility">
        <t>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 <xref target="RFC5245"/>, Sectiom 8.1.1.</t>
      </section>
      <section title="Examples">
        <section title="Switching Between Pairs Based on RTT">
          <t>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.</t>
          <t>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.</t>
        </section>
        <section title="Switching To A New TURN Server">
          <t>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.</t>
          <t>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.</t>
          <t>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
            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.
          </t>
        </section>
        <section title="Switching From WLAN to WWAN">
          <t>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.</t>
          <t>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.</t>
          <t>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.</t>
        </section>
      </section>
    </section>

    <section title="Security Considerations">
      <t>TODO</t>
    </section>

    <section title="IANA Considerations">
      <t>A new ICE option "continuous" has been [will be] registered
      in the "ICE Options" registry created by <xref target="RFC6336"/>.
      </t>
    </section>

    <section title="Acknowledgements">
      <t>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.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &rfc2119;
      &rfc5245;
      &rfc6336;
    </references>

    <references title="Informative References">
      &consent;
      &trickle;
      &redirect;
      &icemob;
      &mprtp;
    </references>

    <section title="Change log">
      <t>Changes in draft -00: <list style="symbols">
        <t>Initial version, from mailing list discussion post-IETF 90.</t>
      </list></t>
    </section>
  </back>
</rfc>