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

["Pal Martinsen (palmarti)" <[e-mail]>]

On 10 Jan 2014, at 17:00 pm, Ari Keränen <[e-mail]> wrote:

> Hi,
> 
> I read the latest draft and have a few questions. In Section 3 the draft says:
> 
>>   ICE [RFC5245] section 4.1.2 states that the formula in section
>>   4.1.2.1 SHOULD be used.  Failing to do so may lead to ICE taking
>>   longer to converge as the checklist no longer will be coordinated.
>>   Therefore responsiveness of ICE candidate checks are improved when
>>   both sides support Happy-Eyeballs, both sides have the same number of
>>   candidate pairs, and both sides use the same Happy Eyeballs promotion
>>   algorithm.
> 
> Do you mean the checklist is no longer coordinated (i.e., matching on both sides) if all those requirements aren't fulfilled? That sounds a bit strange but that's the impression I got from the text.

What we tried to say was that if the two agents have different Happy Eyeball Algorithms ICE might take longer to complete.
Both Alice and Bob used the following formula to sort the checklist: After N numbers of IPv6 addresses, add M numbers of IPv4 addresses. 

   Alice(N=4, M=1)                   Bob(N=2,M=1)
1     IPv6                                     IPv6
2     IPv6                                     IPv6
3     IPv6                                     IPv4(*)
4     IPv6                                     IPv6
5     IPv4(*)                                 IPv6
6     IPv6                                     IPv4(*)
7     IPv6                                     IPv6
8     IPv6                                     IPv6
9     IPv6                                     IPv4(*)
10   IPv4(*)                                 IPv6
11   IPv6                                     IPv6
12   IPv6                                     IPv4(*)
13   IPv6                                     IPv6
14   IPv6                                     IPv6
15   IPv4(*)
16   IPv4(*)

 The initial thought was that having for example different M and N values would cause ICE to take longer to complete. But due to triggered checks different M and N values might actually speed up the ICE negotiation. 

I will update the text using this simple example algorithm, and rewrite Section 3.

> 
> Also, if there is no coordination/signaling between the endpoints, what are the odds they'd end up using the same promotion algorithm?
> 
Exactly, and that might be an advantage.. 

>>   If each ICE agent uses a different algorithm to promote IPv4
>>   candidates, ICE connectivity checks will be as responsive as the
>>   least aggressive algorithm.
> 
> What is "least aggressive algorithm”?

Good question. Regarding what the meaning was I think it was wron.


Rereading the entire draft myself. I realise it is in a pretty bad state. I will do a full rewrite focusing on:

1. Explaining the need for the draft. (Get IPv6 path a head start so we choose that, but try to minimize the delay if the path is broken)
2. Get rid of generic IP address language. We are dealing with IPv6 and IPv4. That is not going to change for a while. (Haing language as if IPv8 was just around the corner just makes it harder to read)
3. Add example algorithm as described in this mail

Thanks for the review, will submit a 05 version before next IETF. 

.-.
Pål-Erik

> 

> 
> Cheers,
> Ari