Re: [MMUSIC] ICE candidate address selection update draft

People involved in this discussion might be interested in

  http://datatracker.ietf.org/doc/draft-ietf-6man-rfc3484bis/

On 07/08/2012 2:30 PM, Pal Martinsen (palmarti) wrote:
>
> On Aug 7, 2012, at 11:53 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:
>
>> 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).
>
>>From a ICE multi platform library developer that is somewhat of a nightmare.
> Guess it can be solved by having a reasonable interface that the application
> that uses the library can fill in the defaults. Having reasonable default values
> is important as some platforms might not be able to set the values.
>
>>>
>>> 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.
>>
> It can at least potentially introduce more "kamikaze" packets and delay the result. The STUN transaction have 10 retransmits and would timeout long after the checklist is empty.
>
> To maintain the speed of ICE negotiation and keep call setup times low I think we should consider looking at the pacing of the conn checks. The rationale behind the pacing was not to overwhelm the NATs. Have the world move slightly towards better NATs? Looking from the perspective of an endpoint sending 1080p60 video streams the pacing seem a bit conservative? And how does the different paths (IPv4, IPv6, multi homed) impact the pacing? Could we do more in parallel without overwhelm the NATs?
>
> I am wondering if we could do something smart with prioritising the checklist and triggered checks to make sure IPv6 wins if there is connectivity? I have to little understanding if IPv6 and all the different addresses to clearly formulate the idea at the moment. (Hoping this may trigger something for someone.)
>
> .-.
> Pål-Erik
>
>
>> --
>> Jonathan Lennox
>> jonathan@vidyo.com
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>