idnits 2.17.1 draft-oreland-dispatch-ice-nicer-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (6 July 2021) is 1024 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dispatch J. Oreland 3 Internet-Draft H. Alvestrand 4 Intended status: Informational Google 5 Expires: 7 January 2022 6 July 2021 7 NICER - a better usage profile on ICE 8 draft-oreland-dispatch-ice-nicer-00 10 Abstract 12 NICER presents an usage profile of ICE that permits more dynamic 13 adaptation to network conditions over the time of a call. 15 Discussion Venues 17 This note is to be removed before publishing as an RFC. 19 Discussion of this document takes place on the mailing list 20 (dispatch@ietf.org), which is archived at 21 https://mailarchive.ietf.org/arch/browse/dispatch/. 23 Source for this draft and an issue tracker can be found at 24 https://github.com/alvestrand/nicer-spec. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 7 January 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 61 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2 62 4. Traditional ICE . . . . . . . . . . . . . . . . . . . . . . . 3 63 5. NICER - the idea . . . . . . . . . . . . . . . . . . . . . . 3 64 6. Standardization requirements . . . . . . . . . . . . . . . . 4 65 7. Possible optimizations . . . . . . . . . . . . . . . . . . . 4 66 8. Implementation issues . . . . . . . . . . . . . . . . . . . . 4 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 11. Normative References . . . . . . . . . . . . . . . . . . . . 5 70 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 TODO Introduction 77 2. Conventions and Definitions 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in BCP 82 14 [RFC2119] [RFC8174] when, and only when, they appear in all 83 capitals, as shown here. 85 3. Problem statement 87 Consider the case of someone walking home while on an Internet-based 88 audio call. 4G coverage in his area is good, but for cost reasons, he 89 prefers to use wifi when available. 91 As he nears his house, the phone picks up a weak wifi signal - high 92 packet loss, low bandwidth, but definitely present. Next to his 93 front door, there is a big tree. As he walks behind the tree, the 94 signal disappears. As he walks in the front door, the wifi signal is 95 strong and stable. 97 What media should the call use while it is progressing through these 98 scenarios? 100 4. Traditional ICE 102 The traditional ([RFC8863]) version of ICE can be briefly described 103 as: 105 * Generate a large number of candidate pairs 107 * Try them in order until one of them works 109 * Start using the working one (ICE controller decides) 111 * Throw away all the other ones 113 * When the chosen pair breaks, do an ICE restart and start over 115 There are extensions specified to this model; one of particular 116 interest is Trickle ICE (RFC 8838), which allows adding more 117 candidates after initialization, forming new sets of candidate pairs 118 without an ICE restart. 120 5. NICER - the idea 122 The idea behind NICER is that rather than keeping a single candidate 123 pair up, the ICE controller will form a list of candidate pairs it 124 considers "potentially viable". The ICE controller will perform STUN 125 Pings (bind requests) on these pairs to keep them alive and get some 126 metrics on quality (RTT, packet loss). 128 When the ICE controller decides that one of these pairs is doing 129 better than the currently active candidate pair, it will switch the 130 active pair to this pair, and relegate the old pair to the 131 "alternate" pool, informing the other party through a BIND request 132 with the "nominated" flag set. 134 The ICE controller will still discard candidate pairs that never 135 started working, and candidate pairs that have a high likelihood of 136 being duplicates of other candidate pairs in the pool. 138 When new network interfaces come up, the ICE controller will use 139 trickle-ICE to communicate with the other party and form new sets of 140 candidate pairs; when interfaces go down, the ICE controller will 141 switch to a still-working interface at once; ICE restart will only 142 happen once all previously usable connections have failed. 144 It follows from the description above that NICER may need to add 145 candidates at any time; the simplest approach compatible with 146 standard ICE is to never send end-of-candidates, but more subtle 147 approaches should be possible. 149 6. Standardization requirements 151 Most of the adaptations needed for NICER are within the ICE 152 controller, and don't need to be standardized. However, there are a 153 few parts that affect messages on the wire, and these call for some 154 standardization effort - either by pushing through existing proposals 155 that cover the need, or by standardizing new features. 157 These are: 159 * Trickle ICE [RFC8838] 161 * Continuous renomination 163 Continuous renomination means that for some subset of candidate pairs 164 not selected, rather than discarding them as mandated by [RFC8863] 165 section 8.3, they will be retained and be made available for 166 selection by sending a check with the USE-CANDIDATE attribute on that 167 candidate pair. One writeup for an extension that would permit this 168 was draft-thatcher-ice-renomination (expired I-D). 170 With these features in place, NICER should be deployable against any 171 system that impelments these features. 173 7. Possible optimizations 175 In Google's experimentation with NICER, we have experiemented with 176 reducing the size of the ping - omitting known parameters and using 177 shorter message-integrity functions. These optimizations may be 178 interesting to standardize, but not essential for making NICER work. 180 8. Implementation issues 182 These are things for which standardization is not needed, but where 183 implementors who want to use NICER need to be aware of them. 185 The definition of "better" is quite fluid and complex. The data 186 available from a connection that is only occasionally pinged is also 187 limited; for instance, bandwidth limitations can't be probed with 188 just occasional probe packets (although guesses can be made). In 189 particular, the ICE concept of "priority" (used to rank candidate 190 pairs consistently at the ICE controller and controlled entities) is 191 not useful for ranking the preferability of candidates for switching. 193 Managing power budgets on mobile devices can be challenging. In 194 particular, pinging interfaces keeps radios alive and therefore 195 consume power; when an interface has no reachable connections, one 196 should avoid pinging it. 198 Given the dynamic nature of RF environments, occasional pinging runs 199 the risk of decisions being taken on stale data, while frequent pings 200 use battery and bandwidth; tuning these tradeoffs requires some 201 attention while implementing. 203 9. Security Considerations 205 Keeping additional paths open increases the attack area for MITM 206 attacks, naturally. So just as in the case of other TURN usages, it 207 is important that the traffic sent over these TURN connections be 208 authenticated and encrypted as appropriate. 210 Shortening the checksum will weaken the barrier to impersonation. 211 This may not matter if the shortened checksum is only used on 212 subsequent pings, not initial handshakes. 214 10. IANA Considerations 216 This document has no IANA actions. 218 11. Normative References 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, 222 DOI 10.17487/RFC2119, March 1997, 223 . 225 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 226 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 227 May 2017, . 229 [RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: 230 Incremental Provisioning of Candidates for the Interactive 231 Connectivity Establishment (ICE) Protocol", RFC 8838, 232 DOI 10.17487/RFC8838, January 2021, 233 . 235 [RFC8863] Holmberg, C. and J. Uberti, "Interactive Connectivity 236 Establishment Patiently Awaiting Connectivity (ICE PAC)", 237 RFC 8863, DOI 10.17487/RFC8863, January 2021, 238 . 240 Acknowledgments 242 TODO acknowledge. 244 Authors' Addresses 246 Jonas Oreland 247 Google 249 Email: jonaso@google.com 251 Harald Alvestrand 252 Google 254 Email: hta@google.com