Re: [MMUSIC] ICE candidate address selection update draft

On Aug 23, 2012, at 2:59 AM, Dan Wing <dwing@cisco.com> wrote:

>> -----Original Message-----
>> From: Jonathan Lennox [mailto:jonathan@vidyo.com]
>> Sent: Tuesday, August 07, 2012 2:53 AM
>> To: Dan Wing; 'Ari Keranen'
>> Cc: mmusic@ietf.org
>> Subject: RE: [MMUSIC] ICE candidate address selection update draft
>> 
>> On Tuesday, August 7 2012, "Dan Wing" wrote to "'Jonathan Lennox', 'Ari
>> Keranen', mmusic@ietf.org" saying:
>> 
>>> Mine would be to take the list of IPv6 and IPv4 addresses and try
>> them
>>> in the order described by ICE (which currently recommends following
>>> the OS's default, which is sometimes hard to get depending on the
>> OS).
>>> But if the first IPv6 candidate didn't return a connectivity checks
>>> quickly (let's say, 150ms), initiate a connectivity check on the
>>> highest priority IPv4 address next.  In that 150ms, based on ICE's
>>> pacing, many IPv6 addresses will have been tried.  150ms gives plenty
>>> of time for IPv6 to 'win', before using an IPv4 resource that is
>>> likely shared with IPv4-only devices.
>> 
>> Can't this result in the endpoints getting out of sync with the order
>> of the checklist?  If one side has started IPv4 while the other hasn't,
>> you won't have the outbound packets coming from one side to create the
>> port bindings.
> 
> Don't we already have that problem if both peers are dual-stack, and 
> one side has many more IPv6 candidates than the other side?

But the checklist consist of candidate pairs. So the checklists on remote and local side should be fairly similar in size? 

> 
> 
> But, to avoid the problem you describe, seems we should try IPv6
> and try IPv4 in a somewhat parallel fashion.  Echos of Happy 
> Eyeballs.
> 
That is a nice speed optimisation.

.-.
Pål-Erik

> -d
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic