draft-ietf-mmusic-trickle-ice-01.txt   draft-ietf-mmusic-trickle-ice-02.txt 
Network Working Group E. Ivov Network Working Group E. Ivov
Internet-Draft Jitsi Internet-Draft Jitsi
Intended status: Standards Track E. Rescorla Intended status: Standards Track E. Rescorla
Expires: August 11, 2014 RTFM, Inc. Expires: July 19, 2015 RTFM, Inc.
J. Uberti J. Uberti
Google Google
February 7, 2014 January 15, 2015
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-mmusic-trickle-ice-01 draft-ietf-mmusic-trickle-ice-02
Abstract Abstract
This document describes an extension to the Interactive Connectivity This document describes an extension to the Interactive Connectivity
Establishment (ICE) protocol that allows ICE agents to send and Establishment (ICE) protocol that allows ICE agents to send and
receive candidates incrementally rather than exchanging complete receive candidates incrementally rather than exchanging complete
lists. With such incremental provisioning, ICE agents can begin lists. With such incremental provisioning, ICE agents can begin
connectivity checks while they are still gathering candidates and connectivity checks while they are still gathering candidates and
considerably shorten the time necessary for ICE processing to considerably shorten the time necessary for ICE processing to
complete. 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 August 11, 2014. This Internet-Draft will expire on July 19, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 23 skipping to change at page 4, line 23
updating check lists, and how trickle ICE implementations should updating check lists, and how trickle ICE implementations should
interoperate with agents that only implement [RFC5245] processing. interoperate with agents that only implement [RFC5245] processing.
This specification does not define usage of trickle ICE with any This specification does not define usage of trickle ICE with any
specific signalling protocol, contrary to [RFC5245] which contains a specific signalling protocol, contrary to [RFC5245] which contains a
usage for ICE with SIP. Such usages would have to be specified in usage for ICE with SIP. Such usages would have to be specified in
separate documents such as for example separate documents such as for example
[I-D.ivov-mmusic-trickle-ice-sip]. [I-D.ivov-mmusic-trickle-ice-sip].
Trickle ICE does however reuse and build upon the SDP syntax defined Trickle ICE does however reuse and build upon the SDP syntax defined
by vanilla ICE. by [RFC5245].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This specification makes use of all terminology defined by the This specification makes use of all terminology defined by the
protocol for Interactive Connectivity Establishment in [RFC5245]. protocol for Interactive Connectivity Establishment in [RFC5245].
Vanilla ICE: The Interactive Connectivity Establishment protocol as Vanilla ICE: The Interactive Connectivity Establishment protocol as
defined in [RFC5245]. defined in [RFC5245]. Through the rest of the text, the terms
vanilla ICE and "RFC5245" are used interchangeably.
Candidate Harvester: A module used by an ICE agent to obtain local Candidate Harvester: A module used by an ICE agent to obtain local
candidates. Candidate harvesters use different mechanisms for candidates. Candidate harvesters use different mechanisms for
discovering local candidates. Some of them would typically make discovering local candidates. Some of them would typically make
use of protocols such as STUN or TURN. Others may also employ use of protocols such as STUN or TURN. Others may also employ
techniques that are not referenced within [RFC5245]. UPnP based techniques that are not referenced within [RFC5245]. UPnP based
port allocation and XMPP Jingle Relay Nodes [XEP-0278] are among port allocation and XMPP Jingle Relay Nodes [XEP-0278] are among
the possible examples. the possible examples.
Trickled Candidates: Candidates that a trickle ICE agent is sending Trickled Candidates: Candidates that a trickle ICE agent is sending
skipping to change at page 7, line 29 skipping to change at page 7, line 29
ICE support is confirmed for both parties, either agent can use full ICE support is confirmed for both parties, either agent can use full
trickle for subsequent offers. trickle for subsequent offers.
4.1. Unilateral Use of Trickle ICE (Half Trickle) 4.1. Unilateral Use of Trickle ICE (Half Trickle)
The idea of using half trickle is about having the caller send a The idea of using half trickle is about having the caller send a
regular, vanilla ICE offer, with a complete set of candidates. This regular, vanilla ICE offer, with a complete set of candidates. This
offer still indicates support for trickle ice, so the answerer is offer still indicates support for trickle ice, so the answerer is
able to respond with an incomplete set of candidates and continue able to respond with an incomplete set of candidates and continue
trickling the rest. Half trickle offers will typically contain an trickling the rest. Half trickle offers will typically contain an
end-of-candidates indication. end-of-candidates indication, although this is not mandatory as, in
case trickle support is confirmed, the offerer may choose to trickle
additional candidates (e.g., additional relay candidates) before it
declares end of trickling.
The mechanism can be used in cases where there is no way for an agent The half trickle mechanism can be used in cases where there is no way
to verify in advance whether a remote party supports trickle ice. for an agent to verify in advance whether a remote party supports
Because it contains a full set of candidates, its first offer can trickle ice. Because it contains a full set of candidates, its first
thus be handled by a regular vanilla ICE agent, while still allowing offer can thus be handled by a regular vanilla ICE agent, while still
a trickle one to use the optimisation defined in this specification. allowing a trickle one to use the optimisation defined in this
This prevents negotiation from failing in the former case while still specification. This prevents negotiation from failing in the former
giving roughly half the trickle ICE benefits in the latter (hence the case while still giving roughly half the trickle ICE benefits in the
name of the mechanism). latter (hence the name of the mechanism).
Use of half trickle is only necessary during an initial offer/answer Use of half trickle is only necessary during an initial offer/answer
exchange. Once both parties have received a session description from exchange. Once both parties have received a session description from
their peer, they can each reliably determine trickle ICE support and their peer, they can each reliably determine trickle ICE support and
use it for all subsequent offer/answer exchanges. use it for all subsequent offer/answer exchanges.
It is worth pointing out that using half trickle may actually bring It is worth pointing out that using half trickle may actually bring
more than just half the improvement in terms of user experience. more than just half the improvement in terms of user experience.
This can happen in cases where an agent starts gathering candidates This can happen in cases where an agent starts gathering candidates
upon user interface cues that a call is pending, such as activity on upon user interface cues that a call is pending, such as activity on
skipping to change at page 20, line 31 skipping to change at page 20, line 31
Figure 2: Example Figure 2: Example
17. Security Considerations 17. Security Considerations
This specification inherits most of its semantics from [RFC5245] and This specification inherits most of its semantics from [RFC5245] and
as a result all security considerations described there remain the as a result all security considerations described there remain the
same. same.
18. Acknowledgements 18. Acknowledgements
The authors would like to thank Bernard Adoba, Christer Holmberg, The authors would like to thank Bernard Aboba, Christer Holmberg,
Dale R. Worley, Enrico Marocco, Flemming Andreasen, Jonathan Lennox Dale R. Worley, Enrico Marocco, Flemming Andreasen, Jonathan Lennox
and Martin Thomson for their reviews and suggestions on improving and Martin Thomson for their reviews and suggestions on improving
this document. this document.
19. References 19. References
19.1. Normative References 19.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 21, line 15 skipping to change at page 21, line 15
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245, April
2010. 2010.
19.2. Informative References 19.2. Informative References
[I-D.ivov-mmusic-trickle-ice-sip] [I-D.ivov-mmusic-trickle-ice-sip]
Ivov, E., Marocco, E., and C. Holmberg, "A Session Ivov, E., Marocco, E., and C. Holmberg, "A Session
Initiation Protocol (SIP) usage for Trickle ICE", draft- Initiation Protocol (SIP) usage for Trickle ICE", draft-
ivov-mmusic-trickle-ice-sip-01 (work in progress), October ivov-mmusic-trickle-ice-sip-02 (work in progress), June
2013. 2014.
[I-D.keranen-mmusic-ice-address-selection] [I-D.keranen-mmusic-ice-address-selection]
Keraenen, A. and J. Arkko, "Update on Candidate Address Keraenen, A. and J. Arkko, "Update on Candidate Address
Selection for Interactive Connectivity Establishment Selection for Interactive Connectivity Establishment
(ICE)", draft-keranen-mmusic-ice-address-selection-01 (ICE)", draft-keranen-mmusic-ice-address-selection-01
(work in progress), July 2012. (work in progress), July 2012.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
 End of changes. 11 change blocks. 
20 lines changed or deleted 24 lines changed or added

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