Subject: Re: [MMUSIC] New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt

From: Ari Keränen <[email-masked]>
Date: Thu, 13 Feb 2014 20:09:36 +0200

On 31/01/14 15:44, Pal Martinsen (palmarti) wrote:
> On 30 Jan 2014, at 12:34 pm, Ari Keränen <[email-masked]> wrote:
>> On 28/01/14 15:49, Pal Martinsen (palmarti) wrote:
[...]
>> What I would find helpful for discussion is that if you could provide a step-by-step example of how the candidate lists are formed and connectivity checks done in cases where a) both support this with same promo algo b) both support this but with different promo algo c) only one endpoint supports this.
>>
>
> As I do believe in running code, I wrote a simple implementation of the algorithm described below.

That's very nice, but unfortunately that didn't compile on my Mac so I 
couldn't give it a try.

>> Also maybe a recommended promo algo would make sense so that there is at least a fair chance that both will use the same algo/values and get most out of this.
>>
> First shot an an algorithm:
>
> 5.  Example Algorithm for Choosing the Local Preference
>
>     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 pr interface priorities needs to
>     be added.  The highest value should be given to the address family
>     that should be prioritized.
>
>          IPv6    IPv4
>           Start   Start
>     65535  60k     59k    58k    57k    56k    55k                    0
>     +--------+------+------+------+------+------+---------------------+
>     |        | IPv6 | IPv4 | IPv6 | IPv4 | IPv6 |                     |
>     |        | (1)  |  (1) |  (2) |  (2) |  (3) |                     |
>     +--------+------+------+------+------+------+---------------------+
>               <- N->
>
>
>     The local preference can be calculated by the given formula:
>
>
>           local_preference = N*2*(Cn/Cmax)
>
>     Where N is the absolute value of IPv6_start-IPv4_start.  This ensures
>     a positive number even if IPv4 is the highest priority.  Cn is the
>     number of current candidates of a specific IP address type and
>     candidate type (HOST, SRFLX, RELAY).  Cmax is the number of allowed
>     consecutive candidates of the same IP address type.
>

Could you give an example how this algorithm and some priority values, 
e.g., from your program, result in the candidate pairs and order of 
checks? Especially the pairing part with respect to different types of 
candidates and IP families is where I'm afraid things may go wrong.

Cheers,
Ari

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 14 Feb 2014 09:36:41 +0000

> That's very nice, but unfortunately that didn't compile on my Mac so I 

Runs fine on my mac. (Famous last words..) But I have ports installed with gcc and the usual *NIX toolchain.
Have not yet figured out to create a x-code project. If time permits..

I should probably have written it in phyton, but my skills in that language is limited.
 
> candidates and IP families is where I'm afraid things may go wrong.

I am struggling a bit with the RFC format, trying to create an readable list that is of any use to the reader.

The generated checklist will depend largely on what values the remote side have chosen. If he the remote side for some reason gave all his candidates a local_preference in the range 64000-65000 the above formula would have no effect. If he chooses more “normal” values we should see an effect.
But the most important thing is that this does not break anything as the ICE spec allows us to play with this value.

My biggest concern now is how the unfrezing works. Reading 7.1.3.2.3 in the ICE spec I realise that some of the sorting of the candidates regarding component might not be optimal, but not sure. Will mark this as an open question in the draft (Will  post in a few hrs, so will not attempt to solve this problem now.)

.-.
Pål-Erik

---

From: Ari Keränen <[email-masked]>
Date: Fri, 14 Feb 2014 17:03:58 +0200

> I should probably have written it in phyton, but my skills in that language is limited.

I have ports and gcc too, but probably missing something then. Will have 
to have a closer look at this later.

> I am struggling a bit with the RFC format, trying to create an readable list that is of any use to the reader.

I didn't mean (necessarily) for the draft, but just on an e-mail, or 
what ever works for you, would be sufficient for now.

> The generated checklist will depend largely on what values the remote side have chosen. If he the remote side for some reason gave all his candidates a local_preference in the range 64000-65000 the…

Is this something that should be advised about in the draft?

> But the most important thing is that this does not break anything as the ICE spec allows us to play with this value.

That sounds good, but I'm still not 100% sure it works, and hence an 
example of the whole procedure with some realistic values would be nice.

> My biggest concern now is how the unfrezing works. Reading 7.1.3.2.3 in the ICE spec I realise that some of the sorting of the candidates regarding component might not be optimal, but not sure. Wil…

OK.

Cheers,
Ari