idnits 2.17.1
draft-jennings-dispatch-snowflake-01.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 :
----------------------------------------------------------------------------
** There are 4 instances of too long lines in the document, the longest one
being 15 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (March 2, 2018) is 2246 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-20) exists of
draft-ietf-ice-rfc5245bis-18
== Outdated reference: A later version (-21) exists of
draft-ietf-ice-trickle-17
Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group C. Jennings
3 Internet-Draft S. Nandakumar
4 Intended status: Standards Track Cisco
5 Expires: September 3, 2018 March 2, 2018
7 Snowflake - A Lighweight, Asymmetric, Flexible, Receiver Driven
8 Connectivity Establishment
9 draft-jennings-dispatch-snowflake-01
11 Abstract
13 Interactive Connectivity Establishment (ICE) (RFC5245) defines
14 protocol machinery for two peers to discover each other and establish
15 connectivity in order to send and receive Media Streams.
17 This draft raises some issues inherent in the assumptions with ICE
18 and proposes a lightweight receiver driven protocol for asymmetric
19 connectivity establishment.
21 Status of This Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at http://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on September 3, 2018.
38 Copyright Notice
40 Copyright (c) 2018 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (http://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
57 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
58 4. Snowflake for connectivity establishment . . . . . . . . . . 4
59 4.1. System Components . . . . . . . . . . . . . . . . . . . . 4
60 4.2. Protocol Workings . . . . . . . . . . . . . . . . . . . . 4
61 4.3. Advantages of Snowflake . . . . . . . . . . . . . . . . . 7
62 4.3.1. Diagnostics . . . . . . . . . . . . . . . . . . . . . 7
63 4.3.2. Timing . . . . . . . . . . . . . . . . . . . . . . . 7
64 4.3.3. Asymmetric Media . . . . . . . . . . . . . . . . . . 8
65 4.3.4. Fast Start . . . . . . . . . . . . . . . . . . . . . 8
66 5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 8
67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
70 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
71 8.2. Informative References . . . . . . . . . . . . . . . . . 8
72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
74 1. Introduction
76 ICE was designed over a decade ago and certain assumptions about the
77 network topology, timing considerations, application complexity have
78 drastically changed since then. Newer additions/clarifications to
79 ICE in [I-D.ietf-ice-rfc5245bis] and Trickle ICE
80 [I-D.ietf-ice-trickle] have indeed help improve its performance and
81 the way the connectivity checks are performed.
83 However, enforcing stringent global pacing requirements coupled with
84 brute force connectivity checks, tightly coupled timing dependencies
85 between the ICE agents, the need for symmetric connection setup, for
86 example, has rendered the protocol inflexible for innovation and
87 increasingly difficult to apply and debug in a dynamic network and
88 evolving application contexts.
90 This specification defines Snowflake, where, like ICE, both sides
91 gather a set of address candidates that may work for communication.
92 However, instead of both sides trying to synchronize connectivity
93 checks in time-coupled fashion, the sending side acts as a slave and
94 sends STUN packets wherever the receiving side tells it to and when
95 it is told to do so. The receiving side is free to choose whatever
96 algorithm and timing it wants to find a path that works. The sender
97 and receiver roles are reversed for media flow in the opposite
98 direction.
100 The current version of this draft builds on its original
101 instantiation submitted in year 2015 as
102
104 2. Terminology
106 In this document, the key words "MUST", "MUST NOT", "SHOULD", "SHOULD
107 NOT", "MAY", and "OPTIONAL" are to be interpreted as described in RFC
108 2119 [RFC2119] and indicate requirement levels for compliant
109 implementations.
111 3. Problem Statement
113 ICE was developed roughly ten years ago and several things have been
114 learned that could be improved:
116 1. It is spectacularly difficult to debug and analyze failures or
117 successes in ICE or develop good automated tests. Many
118 implementations have had significant bugs for long periods of
119 time. This is further complicated by the timing dependency as
120 explained next.
122 2. It is timing dependent. It relies on both sides to to do
123 something (candidate pairing, validation) at roughly the same
124 time and that ability to do this goes down with the number of
125 interfaces and candidates being handled. Mobile interfaces, dual
126 stack agents make this situation worse.
128 3. Differences in interpretation and implementation of the protocol
129 with respect to aggressive vs normal nomination may hinder rapid
130 convergence or may end up in agents choosing suboptimal routes.
132 4. It does not discover asymmetric routes. For example UDP leaving
133 a device may work just fine even though UDP coming into that
134 device may not work at all.
136 5. Many deployments consider using a TURN/Media Router in their
137 topology today in order to support fast session start or ensuring
138 reliable connection (although with small latency overhead). At
139 the time ICE was designed it was not understood if this would be
140 too expensive or not so. ICE works without TURN but better with
141 it.
143 6. The asymmetric nature of the controlling / controlled roles has
144 caused many interoperability problems and bugs. Also Role
145 conflicts might lead to degrade connection setup depending on
146 which side gets the the controlling role.
148 7. Priorities are complicated in dual stack world and ICE is brittle
149 to changes in this part of the algorithm. Although there are
150 advises in [I-D.ietf-ice-dualstack-fairness] specification that
151 might help here.
153 4. Snowflake for connectivity establishment
155 Snowflake is a light weight, asymmetric, flexible and receiver
156 controlled protocol for end points to establish connectivity between
157 them.
159 The following subsections go into further details of its working.
161 4.1. System Components
163 A typical Snowflake operating model has the following components
165 o Sender Agent: A Software agent interested in sending data
166 stream(s) to a remote receiver.
168 o Receiver Agent: A Software agent capable of receiving data
169 stream(s).
171 o Snowflake Agent: A software agent that is expected to have a STUN
172 Client implementation at the minimum for gathering candidates and
173 performing connectivity checks. Sender/Receiver agents are
174 Snowflake agents as well.
176 o CallAgent/Backchannel: Publicly reachable Server in the cloud
177 accessible by both the Sender and the receiver agents, acts as
178 backchannel/message bus for carrying signals between the Snowflake
179 agents.
181 o STUN Server: Optional component for determining the public facing
182 transport address of an agent behind NAT.
184 o TURN Server/Media Router: Recommended component acting as media
185 relay between the agents. A TURN Server can also act as
186 backchannel in certain instantiations.
188 4.2. Protocol Workings
190 The basic principle here is, each side (Receiver Agent) is
191 responsible for discovering a viable path for it's incoming media.
192 It does so by indicating the addresses for the Sender to verify the
193 connectivity. Once a viable path is established, the Sender Agent
194 continues to transmit the media. This process deviates from ICE by
195 negating the need for agent's role (controlled vs controlling),
196 nomination procedures (aggressive vs passive) and tightly coupled
197 symmetric checklists validation.
199 As a precursor to connectivity establishment, the protocol assumes
200 that there exists a dedicated backchannel that the agents can use to
201 exchange protocol control messages.
203 The protocol starts with the Sender Agent conveying its intention to
204 send media via the backchannel to the Receiver agent. The sender
205 does so by sending a "PlaceCall" control message and populates the
206 same with the ICE candidates gathered so far.
208 On receiving the sender's intention to send media (via the
209 backchannel), the Receiver Agent proceeds with gathering the
210 candidates defined by its local policies or previous knowledge of
211 connectivity checks. The Receiver Agent then directs the Sender
212 Agent to carryout STUN connectivity checks towards the receiver by
213 sending the "DoPing" control message via the backchannel. This
214 message is populated with the candidate pair that the receiver wants
215 the sender to verify the reachability.
217 The Receiver Agent may sends multiple "DoPing" messages to the Sender
218 Agent, sending "DoPing" message per candidate pair to be tested for
219 connectivity, as deemed necessary. The order, the timing and the
220 number of candidate pairs to be tested are fully controlled by the
221 Receiver Agent's implementation.
223 On receiving the "DoPing" message with the candidate pair to be
224 tested, the Sender Agent carries out STUN ping checks on that
225 candidate pair. It does so by sending the STUN Binding Request
226 message towards the receiver over the media path (as its done with
227 ICE today). This opens up the required local pinholes and are
228 further maintained by the Sender for the duration of the session.
229 The Sender Agent also ensures that the frequency and the timing of
230 these checks respect the congestion control requirements for the
231 underlying transport.
233 On receiving the STUN Ping from the Sender Agent, the Receiver Agent
234 does the following two things:
236 1. It responds to the connectivity check on the media path by
237 sending a STUN Binding Response.
239 2. It also sends a "GotPing" control message with the details from
240 the STUN Binding Response over the backchannel to the Sender
241 Agent. This is done so that the Sender Agent can verify the
242 connectivity status results over the backchannel as well. This
243 mechanism is especially beneficial for one-sided media scenarios
244 where the Receiver Agent can't send the STUN response to the
245 sender or if the response to STUN connectivity response was lost
246 in transmission.
248 If a successful STUN Ping response was received (either via the media
249 path or the backchannel), there is a viable path for the Sender to
250 transmit the media.
252 The above set of procedures can be continuously performed during the
253 lifetime of the session as and when the Receiver Agent determines
254 better candidates for receiving the media. Such a decision is
255 totally defined by the local policies and can be performed
256 independently of the other side.
258 Below picture captures one instance of protocol exchange where the
259 Receiver Agent indicates the Sender Agent to carry out the
260 connectivity checks. One can envision multiple executions of the
261 protocol as and when receiver has updated its knowledge of addresses
262 or priorities or bandwidth availability.
264 Snowflake Information Flow (One-way Media)
265 ---------------------------------------------
267 Sender Agent CallAgent(backchannel) Receiver Agent
268 | | |
269 | | |
270 | | |
271 |(1) connect to backchannel |
272 |.................................................|
273 | | |
274 | | |
275 |Gather Sender Candidates| |
276 | | |
277 | | |
278 | | |
279 |(2) PlaceCall [Sender Candidates] |
280 |----------------------->| |
281 | | |
282 | | |
283 | |(3) PlaceCall [Sender Candidates]
284 | |----------------------->|
285 | | |
286 | | |
287 | | |Gather Receiver Candidates
288 | | |
289 | | |
290 | | |
291 | |(4) DoPing [Candidate Pair]
292 | |<-----------------------|
293 | | |
294 | | |
295 |(5) DoPing [Candidate Pair] |
296 |<-----------------------| |
297 | | |
298 | | |
299 |(6) STUN Ping (over media path) |
300 |<----------------------------------------------->|
301 | | |
302 | | |
303 | |(7) GotPing (STUN Ping Response)
304 | |<-----------------------|
305 | | |
306 | | |
307 |(8) GotPing (STUN Ping Respnse) |
308 |<-----------------------| |
309 | | |
310 | | |Repeat Steps 4-8 as needed
311 | | |for other candidate pairs
312 | | |
313 | | |
314 | | |
315 |(9) Found a viable path for sending media |
316 |.................................................|
317 | | |
318 | | |
320 4.3. Advantages of Snowflake
322 4.3.1. Diagnostics
324 This makes it very easy to see which outbound connection were sent
325 from the Sender Agent to open a pin hole. Then when the Sender asked
326 the Receiver Agent to send a test STUN Ping, the connectivity can be
327 easily verified. It becomes easier to set up a client with an
328 automated test jig that tests all the combinations and makes sure
329 they work as you only need to test receiving capability and sender
330 capability independently.
332 4.3.2. Timing
334 This more or less removes the timing complexity by allowing both
335 sides to be responsible for their own timing. If it turns out that
336 we can pace things much faster than 50ms then this allows us to take
337 advantage of that without both sides upgrading at the same time.
338 If we end up with a lot more candidates due to v6, mobile etc, this
339 removes the issue we have today where a path might have worked but
340 the two sides did not find it due to timing issues.
342 4.3.3. Asymmetric Media
344 This allows media to be sent in one direction over a path that does
345 not work in the reverse direction.
347 4.3.4. Fast Start
349 Given there exists a dedicated backchannel, this protocol can speed
350 up the media flow by using TURN server for the backchannel, for
351 example. Once either agents learns more about the candidates, each
352 can update the other side to ensure a better low latency path is used
353 for media.
355 5. IANA Consideration
357 TODO
359 6. Security Considerations
361 TODO
363 7. Acknowledgements
365 TODO
367 8. References
369 8.1. Normative References
371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
372 Requirement Levels", BCP 14, RFC 2119,
373 DOI 10.17487/RFC2119, March 1997, .
376 8.2. Informative References
378 [I-D.ietf-ice-dualstack-fairness]
379 Martinsen, P., Reddy, T., and P. Patil, "ICE Multihomed
380 and IPv4/IPv6 Dual Stack Guidelines", draft-ietf-ice-
381 dualstack-fairness-07 (work in progress), November 2016.
383 [I-D.ietf-ice-rfc5245bis]
384 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
385 Connectivity Establishment (ICE): A Protocol for Network
386 Address Translator (NAT) Traversal", draft-ietf-ice-
387 rfc5245bis-18 (work in progress), February 2018.
389 [I-D.ietf-ice-trickle]
390 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,
391 "Trickle ICE: Incremental Provisioning of Candidates for
392 the Interactive Connectivity Establishment (ICE)
393 Protocol", draft-ietf-ice-trickle-17 (work in progress),
394 February 2018.
396 Authors' Addresses
398 Cullen Jennings
399 Cisco
401 Email: fluffy@iii.ca
403 Suhas Nandakumar
404 Cisco
406 Email: snandaku@cisco.com