Subject: [MMUSIC] draft-reddy-mmusic-ice-happy-eyeballs-07

From: Ari Keränen <[email-masked]>
Date: Tue, 15 Jul 2014 19:15:26 +0300

Hi,

I read the latest draft and, without a chair hat on, I think this is 
useful work and would make sense to specify in an RFC.

Regarding where to do the work, I think the best way forward would be to 
have this as a separate draft and ICE bis to have this as a reference on 
how to do candidate prioritization in a dual-stack environment.

Additionally, it would be good for someone designing a different 
algorithm for the candidate prioritization to have some more guidelines 
on how to play around with the values. As you can remember from the past 
versions, it's not always easy to get it right.

And here's a few editorial comments on the draft:

3.  Improving ICE Dual-stack Fairness

    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.

These two sentences seem to be contradicting each other. Maybe it's 
better to start the second one with "However,".

4.  Compatibility

    To allow for earlier connectivity checks for the IPv4
    server reflexive candidates, some of the IPv6 host candidates was
    demoted.

s/was demoted/were demoted/
(or "are demoted")

                   (1)  HOST       IPv6      (1)    212928947

This line seems to be missing the last digit.

Cheers,
Ari

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 17 Jul 2014 20:28:20 +0000

On 15 Jul 2014, at 18:15, Ari Keränen <[email-masked]> wrote:

>From a development perspective I agree. For a already implemented ICE stack it is easier to deal with a new RFC than catching the changes in a ICEbis version. For new implementations I would focus on getting ICE to work and then add improvements like this draft provides later. 

> versions, it's not always easy to get it right.

Yes, the draft currently says its ok to play with the local_preference value because the pair_priority value would be correct due to the formula used when forming the candidate pair. 

There have been some suggestions that getting some metrics collected so we can actually measure the effect on any proposed algorithm. 
I am going to prepare a slide discussing this for the Toronto meeting.

> And here's a few editorial comments on the draft:
Thanks will fix those.

.-.
Pål-Erik

---

From: Ari Keränen <[email-masked]>
Date: Sat, 19 Jul 2014 22:41:20 -0400

>  From a development perspective I agree. For a already implemented ICE stack it is easier to deal with a new RFC than catching the changes in a ICEbis version. For new implementations I would focus…

Makes sense.

> Yes, the draft currently says its ok to play with the local_preference value because the pair_priority value would be correct due to the formula used when forming the candidate pair.

Yes, this is at least one thing to take into account. Also it may make 
sense to stress more the fact that the algorithm must be such that both 
endpoints end up with same (or very similar) checklists, in case someone 
comes up with something smart that doesn't use just the local_preference.

But since you will get the real benefits only if both endpoints use the 
same/similar algorithm, is there some signaling needed to choose the 
right one if one implements more than one?

> I am going to prepare a slide discussing this for the Toronto meeting.

This sounds good too.

Cheers,
Ari