Re: [MMUSIC] ICE candidate address selection update draft

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Jonathan Lennox
> Sent: Monday, August 06, 2012 7:08 PM
> To: Ari Keranen
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] ICE candidate address selection update draft
> 
> On Monday, August 6 2012, Ari Keranen wrote:
> 
> > You have a good point. My main concern is that when you have a long
> list
> > of different kind of IPv6 addresses for each interface (global,
> > link-local, ULA, some temporary addresses, etc.), you will end up
> with a
> > huge checklist of host-host candidates (which have the highest
> > priority). If you have broken v6 connectivity, it's gonna take ages
> > before you move to v4 candidates that work.
> >
> > That being said, perhaps we should keep matching ULAs to globals but
> > just give that combination a lower priority than other host-host
> > candidate pairs. Link-locals we should still match only to link-
> locals
> > (right?).
> 
> I understand the problem, and I agree it'll be an issue.
> 
> Furthermore, if you need to fall back to v4, it's not enough to just
> prioritize all the weird cases below the other host-host pairs -- the
> v4
> address that works will probably be server-reflexive, which you'd
> prefer.
> 
> (If hosts really treat link-local as link-local -- i.e. you'll never
> have a
> router for link-local, and trying to send from link-local to non-link-
> local
> is a black hole or socket error at the sender -- then yes, there's no
> point
> in pairing them with non-link-local addresses.  That's the case I was
> thinking of as "impossible")
> 
> > > That said, if there were a well-defined algorithm to prioritize
> > > sensible checks over absurd ones, that'd be fine.
> >
> > This is the tricky part. Right now the candidates use same priority
> > regardless of the other candidate's type. What we'd like to say is
> "for
> > ULA candidate with ULA pair you need priority X and with other types
> > priority Y". Then another question is what's the sensible trade-off
> > between complexity of prioritization and making these corner cases
> work..
> 
> My quick-and-dirty idea would be to take all the candidate pairs that
> the
> current draft lists as "MUST NOT" combine, and put them in a secondary
> ("stupid") check list which follows all the other checks.  Within the
> secondary list, checks are in the standard ICE priority order.

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.

-d

> One question would be what the relative priority of weird v6
> combinations
> vs. v4 relays should be.
> 
> --
> Jonathan Lennox
> jonathan@vidyo.com
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic