Happy Eyeballs Extension for
ICECisco Systems, Inc.Cessna Business Park, Varthur HobliSarjapur Marathalli Outer Ring RoadBangaloreKarnataka560103Indiatireddy@cisco.comCisco Systems, Inc.BangaloreIndiapraspati@cisco.comCisco Systems, Inc.Philip Pedersens Vei 22LysakerAkershus1325Norwaypalmarti@cisco.comMMUSIC
This document provides guidelines on how to make Interactive
Connectivity Establishment (ICE) conclude faster in IPv4/IPv6
dual-stack scenarios where broken paths exist. The provided
guidelines are backwards compatible with the original ICE
specification.
There is a need to introduce more fairness in the handling of
connectivity checks for different IP address families 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
lead to prioritization of IPv6 over IPv4 for the same
candidate type. Due to this, connectivity checks for
candidates of the same type (host, reflexive or relay) are
sent such that an IP address family is completely depleted
before checks from the other address family are started. This
results in user noticeable setup delays if the path for the
prioritized address family is broken.
To avoid such user noticeable delays when either IPv6 or IPv4
path is broken or excessive slow, this specification
encourages intermingling the different address families when
connectivity checks are performed. Introducing IP address
family fairness into ICE connectivity checks will lead to more
sustained dual-stack IPv4/IPv6 deployment as users will no
longer have an incentive to disable IPv6. The cost is a small
penalty to the address type that otherwise would have been
prioritized.
The guidelines outlined in this specification are backward
compatible with a standard ICE implementation. This
specification only alters the values used to create the
resulting checklists in such a way that the core mechanisms
from ICE are still in effect. The
introduced fairness might be better, but not worse than what
exists today.
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 will be
intermingled with candidates from an alternate IP family. For
example, promoting IPv4 candidates in the presence of many
IPv6 candidates such that an IPv4 address candidate is always
present after a small sequence of IPv6 candidates, i.e.,
reordering candidates such that both IPv6 and IPv4 candidates
get a fair chance during the connectivity check phase. This
makes ICE connectivity checks more responsive to broken path
failures of an address family.
An ICE agent can choose an algorithm or a technique of its
choice to ensure that the resulting check lists have a fair
intermingled mix of IPv4 and IPv6 address families. Modifying
the check list directly can lead to uncoordinated local and
remote check lists that result in ICE taking longer to
complete or in the worst case scenario fail. The best approach
is to modify the formula for calculating the candidate
priority value described in ICE
section 4.1.2.1.
ICE section 4.1.2 states that the
formula in section 4.1.2.1 SHOULD be used to calculate the
candidate priority. The formula is as follows:
ICE section 4.1.2.2 has guidelines
for how the type preference and local preference value should
be chosen. Instead of having a static local preference value
for IPv4 and IPv6 addresses, it is possible to choose this
value dynamically in such a way that IPv4 and IPv6 address
candidate priorities ends up intermingled within the same
candidate type.
It is also possible to dynamically change the type preference
in such a way that IPv4 and IPv6 address candidates end up
intermingled regardless of candidate type. This is useful if
there are a lot of IPv6 host candidates effectively blocking
connectivity checks for IPv4 server reflexive candidates.
The list below shows a sorted local candidate list where the
priority is calculated in such a way that the IPv4 and IPv6
candidates are intermingled. To allow for earlier connectivity
checks for the IPv4 server reflexive candidates, some of the
IPv6 host candidates was demoted. This is just an example of
how a candidate priorities can be calculated to provide better
fairness between IPv4 and IPv6 candidates without breaking any
of the ICE connectivity checks.
Note that the list does not alter the component ID part of the
formula. This keeps the different components (RTP and RTCP)
close in the list. What matters is the ordering of the
candidates with component ID 1. Once the checklist is formed
for a media stream the candidate pair with component ID 1 will
be tested first. If ICE connectivity check is successful then
other candidate pairs with the same foundation will be
unfrozen ( section 5.7.4. Computing
States).
The local and remote agent can have different algorithms for
choosing the local preference and type preference values
without impacting the synchronization between the local and
remote check lists.
The check list is made up by candidate pairs. A candidate pair
is two candidates paired up and given a candidate pair
priority as described in section
5.7.2. Using the pair priority formula:
Where G is the candidate priority provided by the controlling
agent and D the candidate priority provided by the controlled
agent. This ensures that the local and remote check lists are
coordinated.
Even if the two agents have different algorithms for choosing
the candidate priority value to get an intermingled set of
IPv4 and IPv6 candidates, the resulting checklist, that is a
list sorted by the pair priority value, will be identical on
the two agents.
The agent that has promoted IPv4 cautiously i.e. lower IPv4
candidate priority values compared to the other agent, will
influence the check list the most due to (2^32*MIN(G,D)) in
the formula.
These recommendations are backward compatible with a standard
ICE implementation. The resulting local and remote checklist
will still be synchronized. The introduced fairness might be
better, but not worse than what exists today
None.
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, Jonathan Lennox and Balint Menyhart for
their comments and review.
The value space for the local preference is from 0 to 65535
inclusive. This value space can be divided up in chunks for
each IP address family.
An IPv6 and IPv4 start priority must be given. In this example
IPv6 starts at 60000 and IPv4 at 59000. This leaves enough
address space to further play with the values if different
interface priorities needs to be added. The highest value
should be given to the address family that should be
prioritized.
The local preference can be calculated by the given formula:
Address Type specific start value (IPv4 or
IPv6 Start) Absolute value of
IPv6_start-IPv4_start. This ensures a positive number even
if IPv4 is the highest priority.
Number of current candidates of a
specific IP address type and candidate type (host, server
reflexive or relay).
Number of allowed consecutive
candidates of the same IP address type.
Using the values N=abs(60000-59000) and Cmax = 2 yields the
following sorted local candidate list:
The result is an even spread of IPv6 and IPv4 candidates among
the different candidate types (host, server reflexive, relay). The
local preference value is calculated separately for each
candidate type.