Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: Ari Keränen [mailto:[e-mail]]
> Sent: Wednesday, July 31, 2013 9:26 PM
> To: Jonathan Lennox
> Cc: Tirumaleswar Reddy (tireddy); [e-mail]; Martin Thomson
> Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis
> 
> On 7/31/13 4:45 PM, Jonathan Lennox wrote:
> >
> > On Jul 31, 2013, at 4:13 PM, "Tirumaleswar Reddy (tireddy)"
> <[e-mail]> wrote:
> >>
> >> Using the formula in RFC 5245
> >>
> >>    priority = (2^24)*(type preference) +
> >>               (2^8)*(local preference) +
> >>               (2^0)*(256 - component ID)
> >>
> >> Type preference of
> >>   Host candidates > Server-reflexive candidates > Relayed candidates
> >>
> >> (For example host candidate is 126, server-reflexive 105)
> >>
> >> that causes the problem that when candidate pair priority is calculated
> (priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0))
> >> The candidate pair IPv4 (host, server-reflexive) will only be tested only
> after all IPv6 host candidate-pairs, IPv4 host candidate pairs.
> >>
> >> Even if policy table RFC 6724 is changed so that IPv4 addresses have higher
> precedence that does not solve the problem, It will still result in IPv4
> (host, server-reflexive) to be tested only after all IPv4 host candidate
> pairs, IPv6 host candidate-pairs.
> >>
> >> Hence during the WG session, I had explained that by tweaking the candidate
> priority will not solve the problem, but the candidate pair priority has to be
> adjusted after offer/exchange such that after NNN number of preferred IPv6
> candidate pairs the highest-priority IPv4 candidate-pair is tested and the
> above adjustment continued until all candidate pairs of the preferred address
> family are exhausted.
> >
> > The first formula you quote is the one that RFC 5245 defines as recommended,
> not mandatory.  What we're suggesting be changed is not the "local preference"
> field, but actually the calculated 32-bit "priority" field for the candidate.
> You can set your priorities such that some server-reflexive candidates have
> higher priority than some host candidates, and the calculation of the pair's
> 64-bit priority will still work.
> >
> > We need to be pretty careful when defining a new formula for how these
> priorities are set, though.
> 
> If it's only about updating that formula, this indeed looks like a good
> way forward.
> 
> Just need to think how to get all we want to express (and what do we
> actually want to express) in a priority formula that isn't overly
> complex. Expressing things like "some IPv4 host-srvrflx should be
> prioritized over (some) IPv6 host-host but v4 host-host below (some) v6
> host-host" etc may get a bit messy.

How about using the existing recommended formula in RFC 5245 and after the local candidates are prioritized do the following additional steps :
 
a.  If the first 'N' candidates are of the same IP address family, then the highest-priority candidate of the other address family is promoted to position 'N' in the list.

b.  Step b is repeated for rest of candidates. This is continued until all candidates with the preferred address family are exhausted.

This would work even when policy table is modified such that IPv4 addresses have higher precedence than IPv6 using DHCP http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-10. 

--Tiru.
> 
> 
> Cheers,
> Ari