Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol
updated by
- rfc-8863 — Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC)
Extracted elements (28)
Half Trickle exists because Trickle ICE support cannot always be confirmed before the initial ICE description must be sent. By including a full generation of candidates, the initiator ensures compatibility with regular ICE agents while still enabling optimized processing if the responder supports Trickle ICE.
In Trickle ICE, the initiator SHOULD generate and transmit the initial ICE description as early as possible, even with zero candidates, because this enables the remote party to start gathering and trickling its own candidates sooner. The initial ICE description no longer needs to contain a full generation of candidates.
Preserving component order while trickling maintains the regular ICE property that connectivity checks for the same foundation and component are attempted simultaneously by both agents. This simultaneous checking is important for NAT traversal because it allows firewalls to whitelist both endpoints via the hole-punching effect.
Trickle ICE was designed to accelerate session establishment by allowing ICE agents to begin connectivity checks while still gathering candidates, avoiding the blocking sequential gather-then-exchange model of regular ICE. Candidate gathering often involves slow STUN and TURN server queries, so parallelizing gathering with connectivity checks reduces overall establishment time.
An ICE-lite agent supporting Trickle ICE generates a full generation of candidates accompanied by an end-of-candidates indication. A full ICE implementation performing full trickle may send an initial description with no candidates; after receiving the ICE-lite response, it can skip further trickling because the ICE-lite agent will discover candidates as peer-reflexive through connectivity checks.
Half Trickle allows interoperability with regular ICE agents: the initiator gathers a full generation of candidates before sending the initial ICE description, which can be processed by regular ICE agents. The initial ICE description still indicates Trickle ICE support, so a Trickle-capable responder can still use optimized gathering and connectivity checks.
Regular ICE (RFC 8445) can prematurely fail ICE processing when only a subset of candidates are known at checklist formation time — for example, if all initial pairs fail before trickled candidates arrive. Trickle ICE's modified failure conditions (Section 8) are specifically designed to prevent this premature failure.
When receiving trickled candidates, if a redundancy exists between a newly received peer-reflexive remote candidate and an existing pair, the agent SHOULD discard the peer-reflexive pair and update the priority of the existing pair. This prevents priority disagreements that arise when one agent sees a candidate as peer-reflexive and the other sees it as server-reflexive.
A controlled Trickle ICE agent SHOULD convey an end-of-candidates indication after it has completed gathering for a data stream, unless ICE processing terminates before gathering completes.
A Trickle ICE agent MUST keep each checklist in the Running state as long as it expects candidate pairs to be incrementally added to the checklist.
A Trickle ICE agent MUST NOT pair a local candidate until that candidate has been trickled to the remote party.
A using protocol MUST provide methods for incrementally conveying trickled candidates after the initial ICE description, MUST deliver each trickled candidate or end-of-candidates indication exactly once and in order, MUST provide a mechanism for both parties to agree on the ICE session in force, and MUST provide a way to communicate end-of-candidates indications that specify the applicable ICE session.
After an agent conveys the end-of-candidates indication, it MUST NOT trickle any new candidates within that ICE session. Additionally, an agent MUST NOT trickle any new candidates within an ICE session after nomination of a candidate pair.
After an agent has received an end-of-candidates indication, it MUST ignore any newly received candidates for that data stream or data session.
An agent indicating Trickle ICE support via the 'trickle' ICE option MUST provide that token either at the session level or for every data stream; an agent MUST NOT specify Trickle ICE support for some data streams but not others.
If a newly formed candidate pair has a local candidate whose type is server-reflexive, the agent MUST replace the local candidate with its base before completing redundancy tests (applies both when pairing newly gathered local candidates and when receiving trickled remote candidates).
If an agent determines that the remote party does not support Trickle ICE, it MUST fall back to using regular ICE or abandon the entire session.
When candidates are trickled, the using protocol MUST deliver each candidate (and any end-of-candidates indication) to the receiving Trickle ICE implementation exactly once and in the same order it was conveyed. Any retransmissions provided by the using protocol MUST be hidden from the ICE implementation.
When trickling candidates, agents SHOULD respect the order of components as reflected by their component IDs: candidates for a given component SHOULD NOT be conveyed prior to candidates for a component with a lower ID number within the same foundation.
If revealing host IP addresses is a privacy concern (as discussed in RFC 8828 and Section 19 of RFC 8445), agents can generate initial ICE descriptions with no candidates and trickle only candidates that do not reveal host addresses, such as relayed (TURN) candidates.
A Generation is defined as all candidates conveyed within an ICE session correlated with a particular Username Fragment and Password combination. The generation concept is used to correlate trickled candidates and end-of-candidates indications with a specific ICE session, enabling detection of stale updates from a previous session after an ICE restart.
An Empty Checklist is a checklist that initially contains no candidate pairs because they will be incrementally added as candidates are trickled. Unlike regular ICE where all pairs are known at checklist creation, Trickle ICE places every checklist in the Running state immediately, even if empty.
The end-of-candidates indication signals that an agent has completed (or timed out) candidate gathering for a specific ICE session. It MUST specify the generation (Username Fragment and Password combination) to correlate the indication with a particular ICE session, and may be conveyed as part of the initial ICE description, alongside the last candidate, or as a standalone notification.
The 'trickle' ICE option token is used within an ICE description to indicate that the agent supports incremental candidate communication. Its encoding is protocol-specific (e.g., in SDP it appears in the ice-options attribute as defined in RFC 8840).
IANA registered the ICE option 'trickle' in the 'ICE Options' subregistry of the 'Interactive Connectivity Establishment (ICE) registry' per RFC 6336 procedures. The option indicates support for incremental communication of ICE candidates.
Trickle ICE inherits all security considerations from RFC 8445. No new security threats specific to the incremental candidate exchange mechanism are introduced beyond those already described for ICE.
Trickle ICE adds two conditions to the regular ICE failure criteria for a checklist: (1) all candidate gathering has completed and no new local candidates are expected, AND (2) the remote agent has conveyed an end-of-candidates indication for that checklist. Only when both Trickle ICE conditions and the original RFC 8445 conditions are satisfied can a checklist be set to Failed.
When inserting a trickled candidate pair into a checklist, three rules determine initial pair state: Rule 1 — if the pair is topmost in its foundation column (lowest component ID, highest priority), set to Waiting; Rule 2 — if any pair in that foundation has already Succeeded, set to Waiting; Rule 3 — in all other cases, set to Frozen.