Subject: [MMUSIC] Candidate priority in draft-reddy-mmusic-ice-happy-eyeballs-05

From: Balint Menyhart <[email-masked]>
Date: Thu, 30 Jan 2014 13:30:09 +0000

Hi,

This is a comment related to 
http://www.ietf.org/id/draft-reddy-mmusic-ice-happy-eyeballs-05.txt. 
Section 4 states:

    ICE [RFC5245] section 4.1.2.2 has guidelines for how the type
    preference value should be chosen.  Instead of having a static value
    for IPv4 and a static value for IPv6 type of addresses, it is
    possible to choose this value dynamically in such a way that IPv4 and
    IPv6 address candidate priorities ends up intermingled.

    The local and remote agent can have different algorithms for choosing
    the type preference value without any impact on coordination between
    the local and remote check list.

I believe the intention here was to reference the local preference, 
instead of the type preference. The former is meant to distinguish 
between network interfaces from which the candidates have been gathered, 
while the later was intended to distinguish the type of the candidate 
obtained. It sounds to me, that IPv4 / IPv6 difference falls therefore 
in the local preference category, and not the type preference.

 From a different perspective, applying the formula given above:

         priority = (2^24)*(type preference) +
                    (2^8)*(local preference) +
                    (2^0)*(256 - component ID)

it also makes sense to "play" with the less significant bits, which are 
the local preference, as opposed to the more significant bits, which are 
the type preference. This will indeed lead to a finer grained 
intermingling of the IPv4 and IPv6 candidates.

Regards,

Balint