Re: [MMUSIC] ICE candidate address selection update draft

[Jonathan Lennox <[e-mail]>]

Dan Wing writes:

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

No, because the check list consists of candidate *pairs*, and under the current ICE rules both sides see the same list of pairs, and sort them in the same order.

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

ICE connectivity checks are inherently parallel, so some ordering like "likely v6 pairs", "v4 pairs", "unlikely v6 pairs" should accomplish this.

For the full Happy Eyeballs treatment, I suppose we could recommend that an endpoint prioritize its candidates based on which ones worked previously, but that's an optimization and doesn't need to be standardized (so long as these priorities are signaled in the standard manner).

-----Original Message-----
From: Dan Wing [mailto:[e-mail]] 
Sent: Wednesday, August 22, 2012 8:59 PM
To: Jonathan Lennox; 'Ari Keranen'
Cc: [e-mail]
Subject: RE: [MMUSIC] ICE candidate address selection update draft

> -----Original Message-----
> From: Jonathan Lennox [mailto:[e-mail]]
> Sent: Tuesday, August 07, 2012 2:53 AM
> To: Dan Wing; 'Ari Keranen'
> Cc: [e-mail]
> Subject: RE: [MMUSIC] ICE candidate address selection update draft
> 
> On Tuesday, August 7 2012, "Dan Wing" wrote to "'Jonathan Lennox', 
> 'Ari Keranen', [e-mail]" 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, to avoid the problem you describe, seems we should try IPv6
and try IPv4 in a somewhat parallel fashion.  Echos of Happy 
Eyeballs.

-d