[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                        P. Thatcher
Internet-Draft                                                  H. Zhang
Intended status: Standards Track                         T. Brandstetter
Expires: September 22, 2016                                       Google
                                                          March 21, 2016


  ICE Network Cost: Dynamically selecting ICE candidate pairs based on
                  relative cost of network interfaces
                   draft-thatcher-ice-network-cost-00

Abstract

   This document describes an extension to the Interactive Connectivity
   Establishment (ICE) that enables ICE agents to exchange information
   about the relative cost of network interfaces and dynamically choose
   the selected ICE candidate pair based on the cost of both the local
   and remote network interfaces.  For example, if a cellular network
   interface has a higher cost than a Wi-Fi network interface, the ICE
   agents can use that information to prefer candidate pairs with Wi-Fi
   rather than cellular when possible, and only use cellular when
   necessary.

   This document additionally describes a second piece of information,
   network ID, that goes along with the network cost and can be used to
   know when a network interface has changed, even if two network
   interfaces have the same network cost.

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 22, 2016.







Thatcher, et al.       Expires September 22, 2016               [Page 1]


Internet-Draft              ICE Network Cost                  March 2016


Copyright Notice

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Choosing a value for network cost and network ID  . . . . . .   3
   4.  Signaling network cost and network ID . . . . . . . . . . . .   4
   5.  STUN attribute for network cost and network ID  . . . . . . .   4
   6.  Interpreting network cost and network ID  . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   In certain network conditions, ICE agents may prefer to use a network
   interface with a lower cost (for a definition of cost chosen by the
   ICE agent, which need not be directly related to monetary costs).  If
   the controlling side has such a preference, it can unilaterally
   nominate a candidate pair with the network interface with lower cost,
   but if either the controlling side has no such preference, or it
   would like to take the controlled side's preference into account, it
   cannot do so unless the controlled side provides information about
   its network cost.

   Additionally, if the network interface of the controlled side changes
   (such as by using TURN mobility), the controlling side needs updated
   information from the controlled side.

   The controlling side may also wish to select candidate pairs not only
   based on the relative cost between candidate pairs, but also the cost
   relative to the quality of the network path.  For example, if Wi-Fi



Thatcher, et al.       Expires September 22, 2016               [Page 2]


Internet-Draft              ICE Network Cost                  March 2016


   has a much higher cost, but cellular is much higher quality, the
   controlling side may select cellular even though it's higher cost.
   To do so, the controlled side must provide information about the
   network cost relative to the network quality.  For example, if a
   network cost 10 is equivalent to 100ms network RTT, a Wi-Fi with cost
   0 and RTT 150ms will have equal preference to a cellular with cost 10
   and RTT 50ms.

   Although the controlled side already communicates an ICE candidate
   priority, that candidate attribute doesn't meet the needs of this
   situation for the following reasons:

   o  Candidate priority affects ICE check ordering as well as candidate
      pair preference, which is undesirable in this situation, where the
      ICE check order should be maintained, but the candidate pair
      preference should be changed.

   o  Candidate priority cannot change when the network interface
      changes (such as by using TURN mobility)

   o  Candidate priority is only defined relative to other priorities,
      and can't be compared against network quality in a meaningful way.

2.  Terminology

   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 [RFC2119].

   This specification makes use of all terminology defined by the
   protocol for Interactive Connectivity Establishment in [RFC5245].

   Network Cost  A value indicating how much an ICE agent would prefer
      to not use a given network interface.  This may be, but need not
      be related to monetary costs of using the network interface.

   Network ID  An ID that uniquely identifies a network interface.

3.  Choosing a value for network cost and network ID

   Network cost is an integer in the range 0-999, where larger values
   indicate a stronger preference for not using that network interface.

   Each network interface SHOULD have a unique network ID, in the range
   of 0 to (2^16)-1.






Thatcher, et al.       Expires September 22, 2016               [Page 3]


Internet-Draft              ICE Network Cost                  March 2016


4.  Signaling network cost and network ID

   ICE agents MUST signal network cost on each ICE candidate if the cost
   is non-zero.  ICE agents MUST signal network ID on each ICE
   candidate.

   For example, in an SDP candidate line, the attributes could be
   signaled as "network-cost 100 network-id 1".

5.  STUN attribute for network cost and network ID

   To communicate a change in network cost or to communicate network
   cost for peer reflexive candidates, the following STUN attribute is
   defined:

   A 32-bit integer where the first 16 bits are the network ID and the
   second 16 bits are network cost:


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Network ID          |         Network Cost         |


   In the initial ICE checks, ICE agents MUST communicate a network cost
   and network ID if either is non-zero.  The ICE agent MUST communicate
   new values in subsequent ICE checks if the network cost or network ID
   changes.

6.  Interpreting network cost and network ID

   If network cost is communicated via either signaling or STUN
   attribute, the controlling side SHOULD use the network cost of the
   controlled side as part of the criteria to determine which candidate
   pair to select.  It SHOULD use network cost before using candidate
   priorities (network cost takes precedence over candidate priority),
   and it SHOULD NOT change the ICE check order based on network cost.

   If the controlling side chooses to balance network cost against
   network quality, it is RECOMMENDED to treat a difference in network
   cost of 10 as equivalent of a change in network RTT of 100ms.

   Any time the controlling side sees a change in the network cost from
   the controlled side, it MUST recalculate which candidate pair to
   select and nominate the newly selected candidate pair, if it has
   changed.




Thatcher, et al.       Expires September 22, 2016               [Page 4]


Internet-Draft              ICE Network Cost                  March 2016


7.  IANA Considerations

   This specification requests no actions from IANA.

8.  Security Considerations

   TODO

9.  Acknowledgements

   TODO

10.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              DOI 10.17487/RFC5245, April 2010,
              <http://www.rfc-editor.org/info/rfc5245>.

Authors' Addresses

   Peter Thatcher
   Google
   747 6th St S
   Kirkland, WA  98033
   USA

   Email: pthatcher@google.com


   Honghai Zhang
   Google
   747 6th St S
   Kirkland, WA  98033
   USA

   Email: honghaiz@google.com








Thatcher, et al.       Expires September 22, 2016               [Page 5]


Internet-Draft              ICE Network Cost                  March 2016


   Taylor Brandstetter
   Google
   747 6th St S
   Kirkland, WA  98033
   USA

   Email: deadbeef@google.com












































Thatcher, et al.       Expires September 22, 2016               [Page 6]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/