<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-reddy-mmusic-ice-best-interface-pcp-00"
     ipr="trust200902">
  <front>
    <title abbrev="ICE Interface Selection using PCP">Improving ICE Interface
    Selection Using Port Control Protocol (PCP) Flow Extension</title>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marathalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <author fullname="Dan Wing" initials="D." surname="Wing">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>California</region>

          <code>95134</code>

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

        <email>dwing@cisco.com</email>
      </address>
    </author>

    <author fullname="Bill VerSteeg" initials="B." surname="VerSteeg">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>5030 Sugarloaf Parkway</street>

          <city>Lawrenceville</city>

          <code>30044</code>

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

        <email>billvs@cisco.com</email>
      </address>
    </author>

    <author fullname="Reinaldo Penno" initials="R." surname="Penno">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region></region>

          <code>95134</code>

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

        <phone></phone>

        <email>repenno@cisco.com</email>

        <uri></uri>
      </address>
    </author>

    <author fullname="Varun Singh" initials="V" surname="Singh">
      <organization>Aalto University</organization>

      <address>
        <postal>
          <street>School of Electrical Engineering</street>

          <street>Otakaari 5 A</street>

          <city>Espoo</city>

          <region>FIN</region>

          <code>02150</code>

          <country>Finland</country>
        </postal>

        <email>varun.singh@iki.fi</email>

        <uri>http://www.netlab.tkk.fi/~varun/</uri>
      </address>
    </author>

    <date />

    <workgroup>MMUSIC</workgroup>

    <abstract>
      <t>A host with multiple interfaces needs to choose the best interface
      for communication. Oftentimes, this decision is based on a static
      configuration and does not consider the link characteristics of that
      interface, which may affect the user experience.</t>

      <t>This document describes a mechanism for an endpoint to query the link
      characteristics from the access router (the router at the other end of
      the endpoint's access link) using a Port Control Protocol (PCP) Flow
      Extension. This information influences endpoint's Interactive
      Connectivity Establishment (ICE) candidate selection algorithm.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>ICE <xref target="RFC5245"></xref> uses a prioritization formula to
      perform connectivity checks, in which the most preferred address pairs
      are tested first and when a sufficiently good pair is discovered, the
      ICE connectivity tests are stopped. ICE prefers address pairs in the
      following order: transport address directly attached to the endpoint's
      network interface (host candidate), transport address on the public side
      of a NAT (server reflexive candidate), and finally, transport address
      that are allocated on a media relay (relayed candidate). This approach
      works well for an endpoint with a single interface, but is too
      simplistic for endpoints with multiple interfaces. The network
      interfaces may have different link characteristics, but that will not be
      known without the awareness of the upstream and downstream
      characteristics of the access link.</t>

      <t>In this document, an <xref target="RFC5245">ICE agent</xref> uses PCP
      Flow Extension <xref target="I-D.wing-pcp-flowdata"></xref> to determine
      the link characteristics of the host's interfaces, which influence the
      ICE candidate priority.</t>

      <t>As this document explains the interworking of ICE and Port Control
      Protocol (PCP) Flow Extensions, it is beneficial to first read the
      Overview of ICE (Section 2 of <xref target="RFC5245">ICE</xref>) and
      <xref target="I-D.wing-pcp-flowdata">PCP Flowdata Option</xref>.
      Additionally, <xref target="I-D.penno-rtcweb-pcp">PCP for WebRTC</xref>
      describes the problems with traversing NATs and firewalls, current
      techniques used to solve them and the PCP solution in these
      scenarios.</t>
    </section>

    <section anchor="notation" title="Notational Conventions">
      <t>This note uses terminology defined in <xref
      target="RFC5245">ICE</xref> and <xref target="RFC6887">PCP</xref>.</t>
    </section>

    <section anchor="alg_over" title="Algorithm overview">
      <t>The proposed algorithm is backward compatible with existing
      implementations, and does not require any changes other than to the
      selection of candidate priority.</t>

      <t>When an endpoint first joins a network, it determines if the network
      supports PCP Flow Extensions by following the procedures described in
      <xref target="I-D.wing-pcp-flowdata"></xref>. Basically, the endpoint
      sends a PCP Flow Extension probe packet, the response to which provides
      coarse information on the link capabilities. After confirming that PCP
      Flow Extensions are supported on that network interface, the ICE agent
      can use PCP Flow Extensions on that interface (rather than STUN).</t>

      <t>When a media session needs to be established, and the user and
      operator controlled policies on an endpoint permit more than one
      interface for a media session, the ICE agent uses PCP Flow Extensions to
      (a) obtain a mapping from its NAT or firewall and (b) determine the
      characteristics of the link. After receiving the PCP Flow Extension
      responses from its various interfaces, the ICE agent sorts the ICE
      candidates according to the link capacity characteristics. ICE
      candidates from the interface which best fulfills the desired flow
      characteristics is assigned the highest priority and the best suited
      interface should be used to communicate with the TURN server to learn
      the relayed candidate address.</t>

      <t>The ICE agent calculates the priorities of host and server-reflexive
      candidates based on the above steps and signals these candidates in
      offer or answer to the remote peer. After the offer and answer are
      exchanged, the participating ICE agents begin pairing the candidates,
      ordering them into check lists to start the ICE connectivity check phase
      and eventually select the pair of candidates that will be used for
      real-time communication.</t>

      <section title="Changed Link Quality">
        <t>It is possible that the characteristics of a link may change over
        time, and therefore the ICE agent may want to move the media to a
        different interface. For example, if a competing high-bandwidth flow
        starts or finishes its data transmission; the DSL line rate might have
        improved (or degraded); the link capacity may have been dynamically
        increased (or decreased). When link quality changes in such a fashion,
        the PCP Flow Extensions sends a PCP message to the endpoint. Upon
        receiving the message, the ICE agent may decide to move the active
        flow to a more suitable interface and performs ICE restart to trigger
        the switch over of the media streams to the new interface.</t>

        <t>For ICE local relayed candidates, the ICE agent can switch to the
        more suitable interface by refreshing its allocation with the TURN
        server using the procedures explained in section 5 of <xref
        target="I-D.wing-mmusic-ice-mobility">Mobility using TURN </xref>.
        Thus reusing the local relayed candidate on a different interface even
        if the endpoint IP address changes. Therefore, the ICE agent can
        switch over local relayed candidate to the most suited interface that
        meets the requirements of the media stream. This way, even without
        informing the SIP server and remote peer, ICE agent can switch over a
        local relayed candidate to the most suited interface which meets the
        requested flow characteristics.</t>
      </section>
    </section>

    <section anchor="mif" title="Multiple Interfaces">
      <t>If multiple interfaces are available, the ICE agent can use <xref
      target="I-D.wing-pcp-flowdata">PCP Flow Extensions</xref> to determine
      the best path. The advantage is PCP can be used to select the most
      suitable interface for the media streams. When an endpoint has multiple
      interfaces (for example 3G, 4G, WiFi, VPN, etc.), an ICE agent can
      choose the interfaces for media streams according to the path
      characteristics, as discussed in the previous section.</t>

      <section anchor="mif3" title="Multiple Interfaces for media streams">
        <t>If the requested flow characteristics for the media streams cannot
        be handled by a single interface but by multiple interfaces then the
        ICE agent performs the following steps: <list style="symbols">
            <t>ICE agent based on the ICE connectivity results could select
            multiple interfaces for the media session. For example, the ICE
            agent selects to send the audio stream over the WiFi access point
            because it offers (via PCP Flow Extensions) low delay, low packet
            loss and average capacity of 120 Kbps, but for the video stream it
            selects the 3G interface because it offers medium delay, medium
            packet loss and average capacity of 500Kbps.</t>

            <t>Alternatively, the ICE agent on a mobile device may also want
            to select the best suited interface among all the available
            interfaces even if it does not serve the requested flow
            characteristics for all the media streams, so that other
            interfaces can be turned off to increase the battery life of
            cellular connected devices such as smartphones or tablets.</t>
          </list></t>
      </section>

      <section anchor="mif2" title="Availability of New Interfaces">
        <t>If the available interfaces do not meet the requested flow
        characteristics then ICE agent can either proceed as usual using the
        "Recommended Formula" explained in Section 4.1.2.1 of <xref
        target="RFC5245"></xref> to prioritize the candidates or use the Happy
        Eyeballs Extension for ICE algorithm proposed in <xref
        target="I-D.reddy-mmusic-ice-happy-eyeballs"></xref> for dual-stack
        endpoint. When new interfaces become available then ICE agent can use
        PCP Flow Extension to find if the newly available interfaces meet the
        flow characteristics. When a PCP response is received from at least
        one of the new interfaces and if it meets the requirements, the
        endpoint can re-connect to the SIP proxy using the new interface. The
        endpoint uses the candidates indicated in the previous PCP response,
        it exchanges updated offer/answer to trigger ICE restart. Once the ICE
        processing reaches the "Completed state", the ICE endpoint can
        successfully switch the media session over to the new interface. The
        interface initially used for communication can now be turned off
        without disrupting communications.</t>
      </section>
    </section>

    <section title="IANA Considerations">
      <t>None.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>Security considerations discussed in <xref target="RFC6887"></xref>
      are to be taken into account.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>Authors would like to thank Anca Zamfir for comments and review.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.5245"?>

      <?rfc include='reference.I-D.wing-pcp-flowdata'?>

      <?rfc include="reference.RFC.6887" ?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.penno-rtcweb-pcp' ?>

      <?rfc include='reference.I-D.wing-mmusic-ice-mobility' 
?>

      <?rfc include='reference.I-D.reddy-mmusic-ice-happy-eyeballs'?>
    </references>

    <section title="">
      <t></t>

      <section anchor="reuse"
               title="Delay Factor in Discovering the Link Characteristics">
        <t>Some concern has been expressed, that discovering the link
        characteristics may consume more time than using STUN. However, STUN
        will actually take more time than learning link characteristics,
        because a STUN request/response traverses across more routers than a
        PCP Flow Extension request.</t>
      </section>
    </section>
  </back>
</rfc>
