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

Versions: 00                                                            
dispatch                                                      J. Oreland
Internet-Draft                                             H. Alvestrand
Intended status: Informational                                    Google
Expires: 7 January 2022                                      6 July 2021


                 NICER - a better usage profile on ICE
                  draft-oreland-dispatch-ice-nicer-00

Abstract

   NICER presents an usage profile of ICE that permits more dynamic
   adaptation to network conditions over the time of a call.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the mailing list
   (dispatch@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/dispatch/.

   Source for this draft and an issue tracker can be found at
   https://github.com/alvestrand/nicer-spec.

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 https://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 7 January 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Oreland & Alvestrand     Expires 7 January 2022                 [Page 1]


Internet-Draft                    NICER                        July 2021


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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.  Conventions and Definitions . . . . . . . . . . . . . . . . .   2
   3.  Problem statement . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Traditional ICE . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  NICER - the idea  . . . . . . . . . . . . . . . . . . . . . .   3
   6.  Standardization requirements  . . . . . . . . . . . . . . . .   4
   7.  Possible optimizations  . . . . . . . . . . . . . . . . . . .   4
   8.  Implementation issues . . . . . . . . . . . . . . . . . . . .   4
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   11. Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   TODO Introduction

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Problem statement

   Consider the case of someone walking home while on an Internet-based
   audio call. 4G coverage in his area is good, but for cost reasons, he
   prefers to use wifi when available.

   As he nears his house, the phone picks up a weak wifi signal - high
   packet loss, low bandwidth, but definitely present.  Next to his
   front door, there is a big tree.  As he walks behind the tree, the
   signal disappears.  As he walks in the front door, the wifi signal is
   strong and stable.



Oreland & Alvestrand     Expires 7 January 2022                 [Page 2]


Internet-Draft                    NICER                        July 2021


   What media should the call use while it is progressing through these
   scenarios?

4.  Traditional ICE

   The traditional ([RFC8863]) version of ICE can be briefly described
   as:

   *  Generate a large number of candidate pairs

   *  Try them in order until one of them works

   *  Start using the working one (ICE controller decides)

   *  Throw away all the other ones

   *  When the chosen pair breaks, do an ICE restart and start over

   There are extensions specified to this model; one of particular
   interest is Trickle ICE (RFC 8838), which allows adding more
   candidates after initialization, forming new sets of candidate pairs
   without an ICE restart.

5.  NICER - the idea

   The idea behind NICER is that rather than keeping a single candidate
   pair up, the ICE controller will form a list of candidate pairs it
   considers "potentially viable".  The ICE controller will perform STUN
   Pings (bind requests) on these pairs to keep them alive and get some
   metrics on quality (RTT, packet loss).

   When the ICE controller decides that one of these pairs is doing
   better than the currently active candidate pair, it will switch the
   active pair to this pair, and relegate the old pair to the
   "alternate" pool, informing the other party through a BIND request
   with the "nominated" flag set.

   The ICE controller will still discard candidate pairs that never
   started working, and candidate pairs that have a high likelihood of
   being duplicates of other candidate pairs in the pool.

   When new network interfaces come up, the ICE controller will use
   trickle-ICE to communicate with the other party and form new sets of
   candidate pairs; when interfaces go down, the ICE controller will
   switch to a still-working interface at once; ICE restart will only
   happen once all previously usable connections have failed.





Oreland & Alvestrand     Expires 7 January 2022                 [Page 3]


Internet-Draft                    NICER                        July 2021


   It follows from the description above that NICER may need to add
   candidates at any time; the simplest approach compatible with
   standard ICE is to never send end-of-candidates, but more subtle
   approaches should be possible.

6.  Standardization requirements

   Most of the adaptations needed for NICER are within the ICE
   controller, and don't need to be standardized.  However, there are a
   few parts that affect messages on the wire, and these call for some
   standardization effort - either by pushing through existing proposals
   that cover the need, or by standardizing new features.

   These are:

   *  Trickle ICE [RFC8838]

   *  Continuous renomination

   Continuous renomination means that for some subset of candidate pairs
   not selected, rather than discarding them as mandated by [RFC8863]
   section 8.3, they will be retained and be made available for
   selection by sending a check with the USE-CANDIDATE attribute on that
   candidate pair.  One writeup for an extension that would permit this
   was draft-thatcher-ice-renomination (expired I-D).

   With these features in place, NICER should be deployable against any
   system that impelments these features.

7.  Possible optimizations

   In Google's experimentation with NICER, we have experiemented with
   reducing the size of the ping - omitting known parameters and using
   shorter message-integrity functions.  These optimizations may be
   interesting to standardize, but not essential for making NICER work.

8.  Implementation issues

   These are things for which standardization is not needed, but where
   implementors who want to use NICER need to be aware of them.

   The definition of "better" is quite fluid and complex.  The data
   available from a connection that is only occasionally pinged is also
   limited; for instance, bandwidth limitations can't be probed with
   just occasional probe packets (although guesses can be made).  In
   particular, the ICE concept of "priority" (used to rank candidate
   pairs consistently at the ICE controller and controlled entities) is
   not useful for ranking the preferability of candidates for switching.



Oreland & Alvestrand     Expires 7 January 2022                 [Page 4]


Internet-Draft                    NICER                        July 2021


   Managing power budgets on mobile devices can be challenging.  In
   particular, pinging interfaces keeps radios alive and therefore
   consume power; when an interface has no reachable connections, one
   should avoid pinging it.

   Given the dynamic nature of RF environments, occasional pinging runs
   the risk of decisions being taken on stale data, while frequent pings
   use battery and bandwidth; tuning these tradeoffs requires some
   attention while implementing.

9.  Security Considerations

   Keeping additional paths open increases the attack area for MITM
   attacks, naturally.  So just as in the case of other TURN usages, it
   is important that the traffic sent over these TURN connections be
   authenticated and encrypted as appropriate.

   Shortening the checksum will weaken the barrier to impersonation.
   This may not matter if the shortened checksum is only used on
   subsequent pings, not initial handshakes.

10.  IANA Considerations

   This document has no IANA actions.

11.  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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8838]  Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE:
              Incremental Provisioning of Candidates for the Interactive
              Connectivity Establishment (ICE) Protocol", RFC 8838,
              DOI 10.17487/RFC8838, January 2021,
              <https://www.rfc-editor.org/rfc/rfc8838>.

   [RFC8863]  Holmberg, C. and J. Uberti, "Interactive Connectivity
              Establishment Patiently Awaiting Connectivity (ICE PAC)",
              RFC 8863, DOI 10.17487/RFC8863, January 2021,
              <https://www.rfc-editor.org/rfc/rfc8863>.





Oreland & Alvestrand     Expires 7 January 2022                 [Page 5]


Internet-Draft                    NICER                        July 2021


Acknowledgments

   TODO acknowledge.

Authors' Addresses

   Jonas Oreland
   Google

   Email: jonaso@google.com


   Harald Alvestrand
   Google

   Email: hta@google.com



































Oreland & Alvestrand     Expires 7 January 2022                 [Page 6]