Happy Eyeballs Extension for
ICE
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore
Karnataka
560103
India
tireddy@cisco.com
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore
India
praspati@cisco.com
Cisco Systems, Inc.
Philip Pedersens vei 22
Lysaker
Akershus
1325
Norway
palmarti@cisco.com
MMUSIC
This document provides guidelines on how to make ICE conclude faster in IPv4/IPv6 dual-stack
scenarios where broken paths exists.
There is a need to introduce more fairness in the handling of
connectivity checks in dual-stack IPv4/IPv6 ICE scenarios. Section
4.1.2.1 of ICE points to for prioritizing among the different IP
families. is obsoleted by but following the recommendations from the
updated RFC will still lead to prioritization of IPv6 over IPv4 with the
same candidate type. There can be a lot of ICE candidates belonging to
one address family which results in user-noticable setup delays if the
path for that address family is broken.
To avoid such user-noticable delays when the IPv6 path or IPv4 path
is broken, this specification encourages earlier checking of the other
address family. Greater IP address family fairness into ICE connectivity
checks will lead to more sustained IPv6 deployment (so users will no
longer have an incentive to disable IPv6), which incurs only a small
penalty for the IPv4 connectivity checks.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
This document uses terminology defined in .
Candidates SHOULD be prioritized such that a long sequence of
candidates belonging to the same address family be interleaved with
candidates from the alternate IP family. For example, promoting IPv4
candidates in the presence of many IPv6 addresses such that an IPv4
address candidate is always present after a small sequence of IPv6
addresses. This makes ICE connectivity checks more responsive to
failures of an address family by reordering the candidates such that
IPv6 and IPv4 candidates get a fair chance during connectivity
checks.
An ICE agent can choose an algorithm or a technique of its choice to
promote IPv4 candidates.
ICE section 4.1.2 states that the
formula in section 4.1.2.1 SHOULD be used. Failing to do so may lead to
ICE taking longer to converge as the checklist no longer will be
coordinated. Therefore responsiveness of ICE candidate checks are
improved when both sides support Happy-Eyeballs, both sides have the
same number of candidate pairs, and both sides use the same Happy
Eyeballs promotion algorithm.
If each ICE agent uses a different algorithm to promote IPv4
candidates, ICE connectivity checks will be as responsive as the least
aggressive algorithm. This is because the MAX/MIN candiate-pair logic
ensures that for a particular agent, a lower-priority candidate is never
used (for media) until all higher-priority candidates have been
tried.
If only one ICE agent supports Happy-Eyeballs, there is potentially
no change in pacing of ICE connectivity checks and the situation is no
worse than what exists today
STUN connectivity check using MAC computed during key exchanged in
the signaling channel provides message integrity and data origin
authentication as described in section 2.5 of apply to this use.
Authors would like to thank Dan Wing, Ari Keranen, Bernard Aboba,
Martin Thomson and Jonathan Lennox for their comments and review.