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

[Ari Keränen <[e-mail]>]

Hi,

On 28/01/14 15:49, Pal Martinsen (palmarti) wrote:
> Just posted -05 version of the draft.

Thanks! Here's a few comments on the latest version.

The abstract says:

>    This document provides guidelines on how to make ICE [RFC5245]
>    conclude faster in IPv4/IPv6 dual-stack scenarios where broken paths
>    exist.  This will lead to more sustained IPv6 deployment as users
>    will no longer have an incentive to disable IPv6.

Out of (much of) context, especially the second sentence seems like a 
quite strong statement. I guess there could be other reasons than this 
for disabling v6, for example.

And nit: usually abstract should not contain references and open the ICE 
acronym.

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

Not only can the tests take longer, but they can potentially also fail 
if the lists get badly out of sync since once you have made a NAT 
binding with a connectivity check packet, the check to other direction 
must come before the binding expires. But I suppose this will not be a 
problem with the proposed solution since the lists will be in sync?

>    The local and remote agent can have different algorithms for choosing
>    the type preference value without any impact on coordination between
>    the local and remote check list.

What do you mean by "without any impact on coordination"?

>    Where G is the candidate provided by the controlling agent and D the

s/candidate/priority of the candidate/

> Do we ask for WG adoption, or do we need another MMUSIC session discussing this?

Given this new approach, I think it's too early to ask for WG adoption. 
Rather we need more discussion especially here on the list and possibly 
at the meeting.

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.

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.


Cheers,
Ari