< draft-ietf-ice-trickle-12.txt   draft-ietf-ice-trickle-13.txt >
Network Working Group E. Ivov Network Working Group E. Ivov
Internet-Draft Atlassian Internet-Draft Atlassian
Intended status: Standards Track E. Rescorla Intended status: Standards Track E. Rescorla
Expires: December 29, 2017 RTFM, Inc. Expires: January 17, 2018 RTFM, Inc.
J. Uberti J. Uberti
Google Google
P. Saint-Andre P. Saint-Andre
Filament Filament
June 27, 2017 July 16, 2017
Trickle ICE: Incremental Provisioning of Candidates for the Interactive Trickle ICE: Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol Connectivity Establishment (ICE) Protocol
draft-ietf-ice-trickle-12 draft-ietf-ice-trickle-13
Abstract Abstract
This document describes "Trickle ICE", an extension to the This document describes "Trickle ICE", an extension to the
Interactive Connectivity Establishment (ICE) protocol that enables Interactive Connectivity Establishment (ICE) protocol that enables
ICE agents to send and receive candidates incrementally rather than ICE agents to send and receive candidates incrementally rather than
exchanging complete lists. With such incremental provisioning, ICE exchanging complete lists. With such incremental provisioning, ICE
agents can begin connectivity checks while they are still gathering agents can begin connectivity checks while they are still gathering
candidates and considerably shorten the time necessary for ICE candidates and considerably shorten the time necessary for ICE
processing to complete. processing to complete.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 29, 2017. This Internet-Draft will expire on January 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 52 skipping to change at page 2, line 52
17. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . 21 17. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . 21
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
19. Security Considerations . . . . . . . . . . . . . . . . . . . 22 19. Security Considerations . . . . . . . . . . . . . . . . . . . 22
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
21.1. Normative References . . . . . . . . . . . . . . . . . . 22 21.1. Normative References . . . . . . . . . . . . . . . . . . 22
21.2. Informative References . . . . . . . . . . . . . . . . . 22 21.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Interaction with Regular ICE . . . . . . . . . . . . 24 Appendix A. Interaction with Regular ICE . . . . . . . . . . . . 24
Appendix B. Interaction with ICE Lite . . . . . . . . . . . . . 25 Appendix B. Interaction with ICE Lite . . . . . . . . . . . . . 25
Appendix C. Changes from Earlier Versions . . . . . . . . . . . 26 Appendix C. Changes from Earlier Versions . . . . . . . . . . . 26
C.1. Changes from draft-ietf-ice-trickle-11 . . . . . . . . . 26 C.1. Changes from draft-ietf-ice-trickle-12 . . . . . . . . . 26
C.2. Changes from draft-ietf-ice-trickle-10 . . . . . . . . . 26 C.2. Changes from draft-ietf-ice-trickle-11 . . . . . . . . . 26
C.3. Changes from draft-ietf-ice-trickle-09 . . . . . . . . . 26 C.3. Changes from draft-ietf-ice-trickle-10 . . . . . . . . . 27
C.4. Changes from draft-ietf-ice-trickle-08 . . . . . . . . . 27 C.4. Changes from draft-ietf-ice-trickle-09 . . . . . . . . . 27
C.5. Changes from draft-ietf-ice-trickle-07 . . . . . . . . . 27 C.5. Changes from draft-ietf-ice-trickle-08 . . . . . . . . . 27
C.6. Changes from draft-ietf-ice-trickle-06 . . . . . . . . . 27 C.6. Changes from draft-ietf-ice-trickle-07 . . . . . . . . . 27
C.7. Changes from draft-ietf-ice-trickle-05 . . . . . . . . . 27 C.7. Changes from draft-ietf-ice-trickle-06 . . . . . . . . . 27
C.8. Changes from draft-ietf-ice-trickle-04 . . . . . . . . . 27 C.8. Changes from draft-ietf-ice-trickle-05 . . . . . . . . . 27
C.9. Changes from draft-ietf-ice-trickle-03 . . . . . . . . . 27 C.9. Changes from draft-ietf-ice-trickle-04 . . . . . . . . . 27
C.10. Changes from draft-ietf-ice-trickle-02 . . . . . . . . . 28 C.10. Changes from draft-ietf-ice-trickle-03 . . . . . . . . . 28
C.11. Changes from draft-ietf-ice-trickle-01 . . . . . . . . . 28 C.11. Changes from draft-ietf-ice-trickle-02 . . . . . . . . . 28
C.12. Changes from draft-ietf-ice-trickle-00 . . . . . . . . . 28 C.12. Changes from draft-ietf-ice-trickle-01 . . . . . . . . . 28
C.13. Changes from draft-mmusic-trickle-ice-02 . . . . . . . . 28 C.13. Changes from draft-ietf-ice-trickle-00 . . . . . . . . . 28
C.14. Changes from draft-ivov-01 and draft-mmusic-00 . . . . . 28 C.14. Changes from draft-mmusic-trickle-ice-02 . . . . . . . . 28
C.15. Changes from draft-ivov-00 . . . . . . . . . . . . . . . 29 C.15. Changes from draft-ivov-01 and draft-mmusic-00 . . . . . 29
C.16. Changes from draft-rescorla-01 . . . . . . . . . . . . . 30 C.16. Changes from draft-ivov-00 . . . . . . . . . . . . . . . 29
C.17. Changes from draft-rescorla-00 . . . . . . . . . . . . . 30 C.17. Changes from draft-rescorla-01 . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 C.18. Changes from draft-rescorla-00 . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The Interactive Connectivity Establishment (ICE) protocol The Interactive Connectivity Establishment (ICE) protocol
[rfc5245bis] describes mechanisms for gathering candidates, [rfc5245bis] describes mechanisms for gathering candidates,
prioritizing them, choosing default ones, exchanging them with a prioritizing them, choosing default ones, exchanging them with a
remote party, pairing them, and ordering them into check lists. Once remote party, pairing them, and ordering them into check lists. Once
all of these actions have been completed (and only then), the parties all of these actions have been completed (and only then), the parties
can begin a phase of connectivity checks and eventually select the can begin a phase of connectivity checks and eventually select the
pair of candidates that will be used in a media session or for a pair of candidates that will be used in a media session or for a
skipping to change at page 7, line 47 skipping to change at page 7, line 47
ICE description as quickly as possible, so that both parties can ICE description as quickly as possible, so that both parties can
consider the overall session to be under active negotiation as soon consider the overall session to be under active negotiation as soon
as possible.) as possible.)
As noted in Section 3, in application protocols that use SDP the As noted in Section 3, in application protocols that use SDP the
responder's ICE description can indicate support for Trickle ICE by responder's ICE description can indicate support for Trickle ICE by
including a token of "trickle" in the ice-options attribute. including a token of "trickle" in the ice-options attribute.
5.2. Forming Check Lists and Beginning Connectivity Checks 5.2. Forming Check Lists and Beginning Connectivity Checks
After the initiator and responder exchange ICE descriptions, and as As soon as the agents have obtained local and remote candidates, both
soon as they have obtained local and remote candidates, both agents agents begin forming candidate pairs, computing candidate pair
begin forming candidate pairs, computing candidate pair priorities, priorities, ordering candidate pairs, pruning duplicate pairs, and
ordering candidate pairs, pruning duplicate pairs, and creating check creating check lists according to regular ICE procedures
lists according to regular ICE procedures [rfc5245bis]. [rfc5245bis].
According to those procedures, in order for candidate pairing to be According to those procedures, in order for candidate pairing to be
possible and for duplicate candidates to be pruned, the candidates possible and for duplicate candidates to be pruned, the candidates
would need to be provided in the relevant ICE descriptions. Under would need to be provided in the relevant ICE descriptions. Under
Trickle ICE, check lists can be empty until candidate pairs are Trickle ICE, check lists can be empty until candidates are conveyed
conveyed or received. Therefore Trickle ICE agents handle check or received. Therefore Trickle ICE agents handle check lists and
lists and candidate pairing in a slightly different way than regular candidate pairing in a slightly different way than regular ICE
ICE agents: the agents still create the check lists, but they agents: the agents still create the check lists, but they populate
populate the check lists only after they actually have the candidate the check lists only after they actually have the candidate pairs.
pairs.
A Trickle ICE agent initially considers all check lists to be frozen. A Trickle ICE agent initially considers all check lists to be frozen.
It then inspects the first check list and attempts to unfreeze all It then inspects the first check list and attempts to unfreeze all
candidate pairs it has received so far that belong to the first candidate pairs it has received so far that belong to the first
component on the first media stream (i.e., the first media stream component on the first media stream (i.e., the first media stream
that was reported to the ICE implementation from the using that was reported to the ICE implementation from the using
application). If that first component of the first media stream does application). If that first component of the first media stream does
not contain candidates for one or more of the currently known pair not contain candidates for one or more of the currently known pair
foundations, and if candidate pairs already exist for that foundation foundations, and if candidate pairs already exist for that foundation
in one of the following components or media streams, then the agent in one of the following components or media streams, then the agent
skipping to change at page 13, line 23 skipping to change at page 13, line 23
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| m4 (Video.RTCP) | F | | | | | | m4 (Video.RTCP) | F | | | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
Figure 2: Initial Check List State Figure 2: Initial Check List State
Then, as the checks proceed (see Section 6.2.5.4 of [rfc5245bis]), Then, as the checks proceed (see Section 6.2.5.4 of [rfc5245bis]),
for each pair that enters the Succeeded state (denoted here by "S"), for each pair that enters the Succeeded state (denoted here by "S"),
the agent will unfreeze all pairs for all media streams with the same the agent will unfreeze all pairs for all media streams with the same
foundation (e.g., if the pair in column 1, row 1 succeeds then the foundation (e.g., if the pair in column 1, row 1 succeeds then the
agent will unfreeze the pair in column 1, row 2). ICE also specifies agent will unfreeze the pair in column 1, rows 2, 3, and 4).
that, if all the pairs in a media stream for one foundation are
unfrozen (e.g., column 1, rows 1 and 2 representing both components
for the audio stream), then all of the candidate pairs in the entire
column are unfrozen (e.g., column 1, rows 3 and 4).
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| | f1 | f2 | f3 | f4 | f5 | | | f1 | f2 | f3 | f4 | f5 |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| m1 (Audio.RTP) | S | W | W | | | | m1 (Audio.RTP) | S | W | W | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| m2 (Audio.RTCP) | W | F | F | W | | | m2 (Audio.RTCP) | W | F | F | W | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| m3 (Video.RTP) | W | | | | W | | m3 (Video.RTP) | W | | | | W |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
skipping to change at page 14, line 10 skipping to change at page 14, line 5
might call "static" check list sets. This implies that if, for some might call "static" check list sets. This implies that if, for some
reason, a Trickle agent were to begin connectivity checks with all of reason, a Trickle agent were to begin connectivity checks with all of
its pairs already present, the way that pair states change is its pairs already present, the way that pair states change is
indistinguishable from that of a regular ICE agent. indistinguishable from that of a regular ICE agent.
Of course, the major difference with Trickle ICE is that check list Of course, the major difference with Trickle ICE is that check list
sets can be dynamically updated because candidates can arrive after sets can be dynamically updated because candidates can arrive after
connectivity checks have started. When this happens, an agent sets connectivity checks have started. When this happens, an agent sets
the state of the newly formed pair as described below. the state of the newly formed pair as described below.
Case 1: If the newly formed pair is the topmost pair in this column Case 1: If the newly formed pair is the topmost pair in its column
(i.e. the topmost pair among all the check lists for this (i.e. the topmost pair among all the check lists for this
foundation), set the state to Waiting (e.g., this would be the case foundation), set the state to Waiting (e.g., this would be the case
if the newly formed pair were placed in column 5, row 1). if the newly formed pair were placed in column 5, row 1).
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| | f1 | f2 | f3 | f4 | f5 | | | f1 | f2 | f3 | f4 | f5 |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| m1 (Audio.RTP) | S | W | W | | W | | m1 (Audio.RTP) | S | W | W | | W |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| m2 (Audio.RTCP) | W | F | F | W | | | m2 (Audio.RTCP) | W | F | F | W | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| m3 (Video.RTP) | W | | | | | | m3 (Video.RTP) | W | | | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| m4 (Video.RTCP) | W | | | | | | m4 (Video.RTCP) | W | | | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
Figure 4: Check List State with Newly Formed Pair, Case 1 Figure 4: Check List State with Newly Formed Pair, Case 1
Case 2: If the pair immediately above the newly formed pair in this Case 2: If the pair immediately above the newly formed pair in its
column is in the Succeeded state, set the state to Waiting (e.g., column is in the Succeeded state, set the state to Waiting (e.g.,
this would be the case if the pair in column 5, row 1 succeeded and this would be the case if the pair in column 5, row 1 succeeded and
the newly formed pair were placed in column 5, row 2); the newly formed pair were placed in column 5, row 2);
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| | f1 | f2 | f3 | f4 | f5 | | | f1 | f2 | f3 | f4 | f5 |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| m1 (Audio.RTP) | S | W | W | | S | | m1 (Audio.RTP) | S | W | W | | S |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| m2 (Audio.RTCP) | W | F | F | W | W | | m2 (Audio.RTCP) | W | F | F | W | W |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| m3 (Video.RTP) | W | | | | | | m3 (Video.RTP) | W | | | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| m4 (Video.RTCP) | W | | | | | | m4 (Video.RTCP) | W | | | | |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
Figure 5: Check List State with Newly Formed Pair, Case 2 Figure 5: Check List State with Newly Formed Pair, Case 2
Case 3: If there is at least one Succeeded pair in this column above Case 3: If there is at least one Succeeded pair in its column above
the row of the newly formed pair, set the state to Waiting (e.g., the row of the newly formed pair, set the state to Waiting (e.g.,
this would be the case if the pair in column 5, row 1 succeeded and this would be the case if the pair in column 5, row 1 succeeded and
two newly formed pairs were placed in column 5, rows 3 and 4). two newly formed pairs were placed in column 5, rows 3 and 4).
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| | f1 | f2 | f3 | f4 | f5 | | | f1 | f2 | f3 | f4 | f5 |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| m1 (Audio.RTP) | S | W | W | | S | | m1 (Audio.RTP) | S | W | W | | S |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| m2 (Audio.RTCP) | W | F | F | W | W | | m2 (Audio.RTCP) | W | F | F | W | W |
skipping to change at page 15, line 28 skipping to change at page 15, line 23
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
| m4 (Video.RTCP) | W | | | | W | | m4 (Video.RTCP) | W | | | | W |
+-----------------+------+------+------+------+------+ +-----------------+------+------+------+------+------+
Figure 6: Check List State with Newly Formed Pair, Case 3 Figure 6: Check List State with Newly Formed Pair, Case 3
Case 4: In all other cases, set the state to Frozen. Case 4: In all other cases, set the state to Frozen.
8.2. Announcing End of Candidates 8.2. Announcing End of Candidates
Once all candidate gathering is completed or expires for a specific Once all candidate gathering is completed or expires for an ICE
media stream, the agent will generate an "end-of-candidates" session associated with a specific media stream, the agent will
indication for that stream and convey it to the remote agent via the generate an "end-of-candidates" indication for that session and
signaling channel. The exact form of the indication depends on the convey it to the remote agent via the signaling channel. Although
application protocol. The indication can be conveyed in the the exact form of the indication depends on the application protocol,
the indication MUST specify the generation (ufrag/pwd combination) so
that an agent can correlate the end-of-candidates indication with a
particular ICE session. The indication can be conveyed in the
following ways: following ways:
o As part of an initiation request (which would typically be the o As part of an initiation request (which would typically be the
case with the initial ICE description for half trickle) case with the initial ICE description for half trickle)
o Along with the last candidate an agent can send for a stream o Along with the last candidate an agent can send for a stream
o As a standalone notification (e.g., after STUN Binding requests or o As a standalone notification (e.g., after STUN Binding requests or
TURN Allocate requests to a server time out and the agent has is TURN Allocate requests to a server time out and the agent has is
not actively gathering candidates) not actively gathering candidates)
skipping to change at page 19, line 49 skipping to change at page 19, line 47
conveying (i.e., "trickling") additional candidates after conveying (i.e., "trickling") additional candidates after
conveying the initial ICE description (see Section 8). conveying the initial ICE description (see Section 8).
o A signaling protocol MUST deliver each trickled candidate not more o A signaling protocol MUST deliver each trickled candidate not more
than once and in the same order it was conveyed (see Section 8). than once and in the same order it was conveyed (see Section 8).
o A signaling protocol MUST provide a mechanism for both parties to o A signaling protocol MUST provide a mechanism for both parties to
indicate and agree on the ICE session in force (see Section 8). indicate and agree on the ICE session in force (see Section 8).
o A signaling protocol MUST provide a way for parties to communicate o A signaling protocol MUST provide a way for parties to communicate
the end-of-candidates indication (see Section 8.2). the end-of-candidates indication, which MUST specify the
particular ICE session to which the indication applies (see
Section 8.2).
16. Preserving Candidate Order while Trickling 16. Preserving Candidate Order while Trickling
One important aspect of regular ICE is that connectivity checks for a One important aspect of regular ICE is that connectivity checks for a
specific foundation and component are attempted simultaneously by specific foundation and component are attempted simultaneously by
both agents, so that any firewalls or NATs fronting the agents would both agents, so that any firewalls or NATs fronting the agents would
whitelist both endpoints and allow all except for the first whitelist both endpoints and allow all except for the first
("suicide") packets to go through. This is also important to ("suicide") packets to go through. This is also important to
unfreezing candidates at the right time. While not crucial, unfreezing candidates at the right time. While not crucial,
preserving this behavior in Trickle ICE is likely to improve ICE preserving this behavior in Trickle ICE is likely to improve ICE
skipping to change at page 22, line 21 skipping to change at page 22, line 21
If the privacy implications of revealing host addresses on an If the privacy implications of revealing host addresses on an
endpoint device are a concern, agents can generate ICE descriptions endpoint device are a concern, agents can generate ICE descriptions
that contain no candidates and then only trickle candidates that do that contain no candidates and then only trickle candidates that do
not reveal host addresses (e.g., relayed candidates). not reveal host addresses (e.g., relayed candidates).
20. Acknowledgements 20. Acknowledgements
The authors would like to thank Bernard Aboba, Flemming Andreasen, The authors would like to thank Bernard Aboba, Flemming Andreasen,
Rajmohan Banavi, Taylor Brandstetter, Philipp Hancke, Christer Rajmohan Banavi, Taylor Brandstetter, Philipp Hancke, Christer
Holmberg, Ari Keranen, Paul Kyzivat, Jonathan Lennox, Enrico Marocco, Holmberg, Ari Keranen, Paul Kyzivat, Jonathan Lennox, Enrico Marocco,
Pal Martinsen, Thomas Stach, Peter Thatcher, Martin Thomson, Dale R. Pal Martinsen, Nils Ohlmeier, Thomas Stach, Peter Thatcher, Martin
Worley, and Brandon Williams for their reviews and suggestions on Thomson, Dale R. Worley, and Brandon Williams for their reviews and
improving this document. Thanks also to Ari Keranen and Peter suggestions on improving this document. Thanks also to Ari Keranen
Thatcher for chairing the ICE Working Group. and Peter Thatcher for chairing the ICE Working Group.
21. References 21. References
21.1. Normative References 21.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 24, line 35 skipping to change at page 24, line 35
This could be a problem and cause ICE processing to fail prematurely This could be a problem and cause ICE processing to fail prematurely
in a number of scenarios. Consider the following case: in a number of scenarios. Consider the following case:
1. Alice and Bob are both located in different networks with Network 1. Alice and Bob are both located in different networks with Network
Address Translation (NAT). Alice and Bob themselves have Address Translation (NAT). Alice and Bob themselves have
different address but both networks use the same private internet different address but both networks use the same private internet
block (e.g., the "20-bit block" 172.16/12 specified in block (e.g., the "20-bit block" 172.16/12 specified in
[RFC1918]). [RFC1918]).
2. Alice conveys Bob the candidate 172.16.0.1 which also happens to 2. Alice conveys to Bob the candidate 172.16.0.1 which also happens
correspond to an existing host on Bob's network. to correspond to an existing host on Bob's network.
3. Bob creates a check list consisting solely of 172.16.0.1 and 3. Bob creates a check list consisting solely of 172.16.0.1 and
starts checks. starts checks.
4. These checks reach the host at 172.16.0.1 in Bob's network, which 4. These checks reach the host at 172.16.0.1 in Bob's network, which
responds with an ICMP "port unreachable" error; per [rfc5245bis] responds with an ICMP "port unreachable" error; per [rfc5245bis]
Bob marks the transaction as Failed. Bob marks the transaction as Failed.
At this point the check list only contains Failed candidates and the At this point the check list only contains Failed candidates and the
valid list is empty. This causes the media stream and potentially valid list is empty. This causes the media stream and potentially
all ICE processing to fail. all ICE processing to fail, even though if trickle agents could
subsequently convey candidates that would cause previously empty
check lists to become non-empty.
A similar race condition would occur if the initial ICE description A similar race condition would occur if the initial ICE description
from Alice contain only candidates that can be determined as from Alice contain only candidates that can be determined as
unreachable from any of the candidates that Bob has gathered (e.g., unreachable from any of the candidates that Bob has gathered (e.g.,
this would be the case if Bob's candidates only contain IPv4 this would be the case if Bob's candidates only contain IPv4
addresses and the first candidate that he receives from Alice is an addresses and the first candidate that he receives from Alice is an
IPv6 one). IPv6 one).
Another potential problem could arise when a non-trickle ICE Another potential problem could arise when a non-trickle ICE
implementation initiates an interaction with a Trickle ICE implementation initiates an interaction with a Trickle ICE
skipping to change at page 26, line 32 skipping to change at page 26, line 33
In addition to reducing signaling traffic this approach also removes In addition to reducing signaling traffic this approach also removes
the need to discover STUN bindings or make TURN allocations, which the need to discover STUN bindings or make TURN allocations, which
may considerably lighten ICE processing. may considerably lighten ICE processing.
Appendix C. Changes from Earlier Versions Appendix C. Changes from Earlier Versions
Note to the RFC-Editor: please remove this section prior to Note to the RFC-Editor: please remove this section prior to
publication as an RFC. publication as an RFC.
C.1. Changes from draft-ietf-ice-trickle-11 C.1. Changes from draft-ietf-ice-trickle-12
o Specified that the end-of-candidates indication must include the
generation (ufrag/pwd) to enable association with a particular ICE
session.
o Further editorial fixes to address WGLC feedback.
C.2. Changes from draft-ietf-ice-trickle-11
o Editorial and terminological fixes to address WGLC feedback. o Editorial and terminological fixes to address WGLC feedback.
C.2. Changes from draft-ietf-ice-trickle-10 C.3. Changes from draft-ietf-ice-trickle-10
o Minor editorial fixes. o Minor editorial fixes.
C.3. Changes from draft-ietf-ice-trickle-09 C.4. Changes from draft-ietf-ice-trickle-09
o Removed immediate unfreeze upon Fail. o Removed immediate unfreeze upon Fail.
o Specified MUST NOT regarding ice-options. o Specified MUST NOT regarding ice-options.
o Changed terminology regarding initial ICE parameters to avoid o Changed terminology regarding initial ICE parameters to avoid
implementer confusion. implementer confusion.
C.4. Changes from draft-ietf-ice-trickle-08 C.5. Changes from draft-ietf-ice-trickle-08
o Reinstated text about in-order processing of messages as a o Reinstated text about in-order processing of messages as a
requirement for signaling protocols. requirement for signaling protocols.
o Added IANA registration template for ICE option. o Added IANA registration template for ICE option.
o Corrected Case 3 rule in Section 8.1.1 to ensure consistency with o Corrected Case 3 rule in Section 8.1.1 to ensure consistency with
regular ICE rules. regular ICE rules.
o Added tabular representations to Section 8.1.1 in order to o Added tabular representations to Section 8.1.1 in order to
illustrate the new pair rules. illustrate the new pair rules.
C.5. Changes from draft-ietf-ice-trickle-07 C.6. Changes from draft-ietf-ice-trickle-07
o Changed "ICE description" to "candidate information" for o Changed "ICE description" to "candidate information" for
consistency with 5245bis. consistency with 5245bis.
C.6. Changes from draft-ietf-ice-trickle-06 C.7. Changes from draft-ietf-ice-trickle-06
o Addressed editorial feedback from chairs' review. o Addressed editorial feedback from chairs' review.
o Clarified terminology regarding generations. o Clarified terminology regarding generations.
C.7. Changes from draft-ietf-ice-trickle-05 C.8. Changes from draft-ietf-ice-trickle-05
o Rewrote the text on inserting a new pair into a check list. o Rewrote the text on inserting a new pair into a check list.
C.8. Changes from draft-ietf-ice-trickle-04 C.9. Changes from draft-ietf-ice-trickle-04
o Removed dependency on SDP and offer/answer model. o Removed dependency on SDP and offer/answer model.
o Removed mentions of aggressive nomination, since it is deprecated o Removed mentions of aggressive nomination, since it is deprecated
in 5245bis. in 5245bis.
o Added section on requirements for signaling protocols. o Added section on requirements for signaling protocols.
o Clarified terminology. o Clarified terminology.
o Addressed various WG feedback. o Addressed various WG feedback.
C.9. Changes from draft-ietf-ice-trickle-03 C.10. Changes from draft-ietf-ice-trickle-03
o Provided more detailed description of unfreezing behavior, o Provided more detailed description of unfreezing behavior,
specifically how to replace pre-existing peer-reflexive candidates specifically how to replace pre-existing peer-reflexive candidates
with higher-priority ones received via trickling. with higher-priority ones received via trickling.
C.10. Changes from draft-ietf-ice-trickle-02 C.11. Changes from draft-ietf-ice-trickle-02
o Adjusted unfreezing behavior when there are disparate foundations. o Adjusted unfreezing behavior when there are disparate foundations.
C.11. Changes from draft-ietf-ice-trickle-01 C.12. Changes from draft-ietf-ice-trickle-01
o Changed examples to use IPv6. o Changed examples to use IPv6.
C.12. Changes from draft-ietf-ice-trickle-00 C.13. Changes from draft-ietf-ice-trickle-00
o Removed dependency on SDP (which is to be provided in a separate o Removed dependency on SDP (which is to be provided in a separate
specification). specification).
o Clarified text about the fact that a check list can be empty if no o Clarified text about the fact that a check list can be empty if no
candidates have been sent or received yet. candidates have been sent or received yet.
o Clarified wording about check list states so as not to define new o Clarified wording about check list states so as not to define new
states for "Active" and "Frozen" because those states are not states for "Active" and "Frozen" because those states are not
defined for check lists (only for candidate pairs) in ICE core. defined for check lists (only for candidate pairs) in ICE core.
o Removed open issues list because it was out of date. o Removed open issues list because it was out of date.
o Completed a thorough copy edit. o Completed a thorough copy edit.
C.13. Changes from draft-mmusic-trickle-ice-02 C.14. Changes from draft-mmusic-trickle-ice-02
o Addressed feedback from Rajmohan Banavi and Brandon Williams. o Addressed feedback from Rajmohan Banavi and Brandon Williams.
o Clarified text about determining support and about how to proceed o Clarified text about determining support and about how to proceed
if it can be determined that the answering agent does not support if it can be determined that the answering agent does not support
Trickle ICE. Trickle ICE.
o Clarified text about check list and timer updates. o Clarified text about check list and timer updates.
o Clarified when it is appropriate to use half trickle or to send no o Clarified when it is appropriate to use half trickle or to send no
candidates in an offer or answer. candidates in an offer or answer.
o Updated the list of open issues. o Updated the list of open issues.
C.14. Changes from draft-ivov-01 and draft-mmusic-00 C.15. Changes from draft-ivov-01 and draft-mmusic-00
o Added a requirement to trickle candidates by order of components o Added a requirement to trickle candidates by order of components
to avoid deadlocks in the unfreezing algorithm. to avoid deadlocks in the unfreezing algorithm.
o Added an informative note on peer-reflexive candidates explaining o Added an informative note on peer-reflexive candidates explaining
that nothing changes for them semantically but they do become a that nothing changes for them semantically but they do become a
more likely occurrence for Trickle ICE. more likely occurrence for Trickle ICE.
o Limit the number of pairs to 100 to comply with 5245. o Limit the number of pairs to 100 to comply with 5245.
o Added clarifications on the non-importance of how newly discovered o Added clarifications on the non-importance of how newly discovered
candidates are trickled/sent to the remote party or if this is candidates are trickled/sent to the remote party or if this is
done at all. done at all.
o Added transport expectations for trickled candidates as per Dale o Added transport expectations for trickled candidates as per Dale
Worley's recommendation. Worley's recommendation.
C.15. Changes from draft-ivov-00 C.16. Changes from draft-ivov-00
o Specified that end-of-candidates is a media level attribute which o Specified that end-of-candidates is a media level attribute which
can of course appear as session level, which is equivalent to can of course appear as session level, which is equivalent to
having it appear in all m-lines. Also made end-of-candidates having it appear in all m-lines. Also made end-of-candidates
optional for cases such as aggressive nomination for controlled optional for cases such as aggressive nomination for controlled
agents. agents.
o Added an example for ICE lite and Trickle ICE to illustrate how, o Added an example for ICE lite and Trickle ICE to illustrate how,
when talking to an ICE lite agent doesn't need to send or even when talking to an ICE lite agent doesn't need to send or even
discover any candidates. discover any candidates.
skipping to change at page 30, line 5 skipping to change at page 30, line 17
o Closed the Open Issue about use about what to do with cands o Closed the Open Issue about use about what to do with cands
received after end-of-cands. Solution: ignore, do an ICE restart received after end-of-cands. Solution: ignore, do an ICE restart
if you want to add something. if you want to add something.
o Added more terminology, including trickling, trickled candidates, o Added more terminology, including trickling, trickled candidates,
half trickle, full trickle, half trickle, full trickle,
o Added a reference to the SIP usage for Trickle ICE as requested at o Added a reference to the SIP usage for Trickle ICE as requested at
the Boston interim. the Boston interim.
C.16. Changes from draft-rescorla-01 C.17. Changes from draft-rescorla-01
o Brought back explicit use of Offer/Answer. There are no more o Brought back explicit use of Offer/Answer. There are no more
attempts to try to do this in an O/A independent way. Also attempts to try to do this in an O/A independent way. Also
removed the use of ICE Descriptions. removed the use of ICE Descriptions.
o Added SDP specification for trickled candidates, the trickle o Added SDP specification for trickled candidates, the trickle
option and 0.0.0.0 addresses in m-lines, and end-of-candidates. option and 0.0.0.0 addresses in m-lines, and end-of-candidates.
o Support and Discovery. Changed that section to be less abstract. o Support and Discovery. Changed that section to be less abstract.
As discussed in IETF85, the draft now says implementations and As discussed in IETF85, the draft now says implementations and
skipping to change at page 30, line 35 skipping to change at page 30, line 47
can pre-gather part or all of your candidates before the user can pre-gather part or all of your candidates before the user
actually presses the call button. actually presses the call button.
o Added a short section about subsequent offer/answer exchanges. o Added a short section about subsequent offer/answer exchanges.
o Added a short section about interactions with ICE Lite o Added a short section about interactions with ICE Lite
implementations. implementations.
o Added two new entries to the open issues section. o Added two new entries to the open issues section.
C.17. Changes from draft-rescorla-00 C.18. Changes from draft-rescorla-00
o Relaxed requirements about verifying support following a o Relaxed requirements about verifying support following a
discussion on MMUSIC. discussion on MMUSIC.
o Introduced ICE descriptions in order to remove ambiguous use of o Introduced ICE descriptions in order to remove ambiguous use of
3264 language and inappropriate references to offers and answers. 3264 language and inappropriate references to offers and answers.
o Removed inappropriate assumption of adoption by RTCWEB pointed out o Removed inappropriate assumption of adoption by RTCWEB pointed out
by Martin Thomson. by Martin Thomson.
 End of changes. 33 change blocks. 
71 lines changed or deleted 82 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/