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

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jul 2013 09:22:13 +0200

http://tools.ietf.org/html/rfc5245#section-4.1.2.1

After talking to Jonathan, several things have become apparent.

The prioritization calculation described in Section 4.1.2.1 of RFC
5245 is not mandatory, it's SHOULD only.  This means that the guidance
regarding prioritization of IPv6 over IPv4 is not applied as strictly
and blindly as implied by the happy eyeballs draft.  Implementations
can choose a different prioritization.  (I was under the
misapprehension that only part of the priority was signaled, but
that's clearly not the case.)

That implies to me that the happy-eyeballs draft is, as best, only
worth pursuing as an information addendum that provides guidance on
non-stupid selection of priorities for dual-stack hosts.

However, given the existence of an RFC5245bis effort, I am going to
suggest that the guidance provided instead be folded into a revised
Section 4.1.2.1.

Another problem that can be addressed at the same time is a removal of
all the normative language that surrounds this optional feature.  The
current 4.1.2.1 has lots of "MUST" statements that are both
unnecessary and confusing.

--Martin

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 31 Jul 2013 00:31:43 -0700

I agree that it doesn't make sense to pursue the happy-eyeballs draft and that folding fixes into RFC 5245bis is the best approach. 
 
A number of ICE implementations do not follow the priority guidance in RFC 5245 Section 4.1.2.1 because it doesn't work, and also because guidelines such as DoD 2008 UCR Change 3 require that implementations be able to prioritize IPv4 over IPv6.   So in practice, the advice in RFC 5245 Section 4.1.2.1 has long been overtaken by events. 
 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Ari Keränen <[email-masked]>
Date: Wed, 31 Jul 2013 11:19:50 +0200

Hi,

If we can do this as updated recommendations on how to prioritize the 
candidates, then I think it makes a lot of sense to integrate this into 
5245bis. If it gets much more complicated than this, probably separate 
document makes more sense.

Tiru mentioned that simply tweaking the priorities may not work in all 
cases, so perhaps we should have a look at those cases and see if we can 
make them work.

Cheers,
Ari (as individual)

On 7/31/13 9:31 AM, Bernard Aboba wrote:
> I agree that it doesn't make sense to pursue the happy-eyeballs draft
> and that folding fixes into RFC 5245bis is the best approach.
>
> A number of ICE implementations do not follow the priority guidance in
> RFC 5245 Section 4.1.2.1 because it doesn't work, and also because
> guidelines such as DoD 2008 UCR Change 3 require that implementations be
> able to prioritize IPv4 over IPv6.   So in practice, the advice in RFC
> 5245 Section 4.1.2.1 has long been overtaken by events.
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jul 2013 11:25:22 +0200

> cases, so perhaps we should have a look at those cases and see if we can

I don't believe that to be a problem.  Obviously, unless both peers
are doing the same sort of prioritization, you can get some silly
results, but that's always going to be a hazard.

I don't believe that we need any additional recommendations.

---

From: Dan Wing <[email-masked]>
Date: Wed, 31 Jul 2013 13:19:26 +0200

> I don't believe that we need any additional recommendations.

I agree the happy eyeballs recommendation (or, "non-stupid selection of priorities for dual-stack hosts") would best be folded into RFC5245bis.

However, about a year ago Jonathan Lennox had expressed some concern that if the two peers have different ordering, their suicide packets (necessary to create mappings in their own respective NATs) would have to suffer an additional retry.  I guess that is okay, and why you said it isn't a problem.  I'm fine with that, if that's what you meant.  ICE has its SHOULD for the ordering and chooses one end to be authoritative for the ordering to avoid the problem of each peer using a different order.  If we're confident that guidance in ICE is over-stated and unnecessary, that certainly makes things easier that the two ICE peers can choose their own ordering willy-nilly.

-d

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jul 2013 13:51:23 +0200

> I agree the happy eyeballs recommendation (or, "non-stupid selection of priorities for dual-stack hosts") would best be folded into RFC5245bis.

Great.

> However, about a year ago Jonathan Lennox had expressed some concern that if the two peers have different ordering, their suicide packets (necessary to create mappings in their own respective NATs)…

I don't believe that, except for the pathological case where there is
a collision in priority values, this results in peers generating a
different priority order for candidate pairs.  Even in those
pathological cases, the difference in times that arises from this
(i.e., the 20ms pacing timer) is probably still *significantly*
smaller than the delay that arises from the fact that the signaling
information is complete at the answerer well before the signaling
arrives at the offerer.

---

From: Dan Wing <[email-masked]>
Date: Wed, 31 Jul 2013 14:37:15 +0200

> information is complete at the answerer well before the signaling

I agree, but I would like a careful analysis before we declare ICE-CONTROLLED/ICE-CONTROLLING was an over-design of ICE, which is what we're saying if both peers are allowed to choose their own priority order.  And whatever the result of that analysis it should become part of rfc5245bis.

-d

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 31 Jul 2013 08:44:05 -0400

> However, about a year ago Jonathan Lennox had expressed some concern that if the two peers have different ordering, their suicide packets (necessary to create mappings in their own respective NATs)…

If the two peers have different ordering for their *check lists*, then yes, you get a problem.

However, if the two peers are both following the check list ordering algorithm of section 5.7.2 of RFC 5245 -- based on the signaled candidate priorities -- I think it doesn't matter whether they're both using the section 4.1.2.1 algorithm to calculate their *candidate* priorities.

This is confusing because section 4.1.2 claims there *will* be a problem.  I can't figure out why this would be true, though.  I'm inclined to suspect this is a mistake in RFC 5245.

--
Jonathan Lennox
[email-masked]

---

From: Dan Wing <[email-masked]>
Date: Wed, 31 Jul 2013 14:55:45 +0200

> This is confusing because section 4.1.2 claims there *will* be a problem.  I can't figure out why this would be true, though.  I'm inclined to suspect this is a mistake in RFC 5245.

Works for me.

-d

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jul 2013 14:56:50 +0200

> I agree, but I would like a careful analysis before we declare ICE-CONTROLLED/ICE-CONTROLLING was an over-design of ICE, which is what we're saying if both peers are allowed to choose their own pri…

This has absolutely no impact on ICE-CONTROLLED/ICE-CONTROLLING roles
or any of the other mandatory features of ICE.

In ICE, both peers select a priority order for their own candidates.
Check lists are ordered based on the mandatory formula described in
Section 5.7.2.  http://tools.ietf.org/html/rfc5245#section-5.7.2

ICE-CONTROLLED/ICE-CONTROLLING *is* over-designed, but that's never
been brought up until you mentioned it.

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 31 Jul 2013 09:02:16 -0400

> I agree, but I would like a careful analysis before we declare ICE-CONTROLLED/ICE-CONTROLLING was an over-design of ICE, which is what we're saying if both peers are allowed to choose their own pri…

I know you sent this before my latest comment, but just to get it on the record -- ICE-CONTROLLED/ICE-CONTROLLING affects the section 5.7.2 algorithm, and so is important for the two sides to agree on a check list ordering.  It doesn't affect the section 4.1.2.1 algorithm.

--
Jonathan Lennox
[email-masked]

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 31 Jul 2013 14:13:44 +0000

> -----Original Message-----
> From: Ari Keränen [mailto:[email-masked]]
> Sent: Wednesday, July 31, 2013 2:50 PM
> To: [email-masked]
> Cc: Bernard Aboba; Martin Thomson; Tirumaleswar Reddy (tireddy)
> Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis
> 
> Hi,
> 

Hi Ari,

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.

This will gave a chance for candidate pair with server-reflexive candidates to be tested earlier, which is not possible just by increasing the local candidate priority.

Best Regards,
--Tiru.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jul 2013 16:34:48 +0200

>               (2^0)*(256 - component ID)

This formula is just a recommendation (a SHOULD, to be fair).  So the
rest of your thesis isn't really valid.

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 31 Jul 2013 10:45:08 -0400

> 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 af…

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.

--
Jonathan Lennox
[email-masked]

---

From: Ari Keränen <[email-masked]>
Date: Wed, 31 Jul 2013 17:56:24 +0200

> 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.

Cheers,
Ari

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jul 2013 18:16:21 +0200

On 31 July 2013 17:56, Ari Keränen <[email-masked]> wrote:
> overly complex

Yes.  Given that this is a very small part of a spec that already fits
that description, we need to be careful.