Re: [MMUSIC] ICE candidate address selection update draft

On Aug 8, 2012, at 6:05 PM, Dan Wing <dwing@cisco.com> wrote:

>> -----Original Message-----
>> From: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]
>> Sent: Tuesday, August 07, 2012 11:30 AM
>> To: Jonathan Lennox
>> Cc: Dan Wing (dwing); Ari Keranen; mmusic@ietf.org
>> Subject: Re: [MMUSIC] ICE candidate address selection update draft
>> 
>> 
>> 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.
> 
> Yes.  And also to reduce the concern that ICE connectivity checks 
> could flood a link.
> 
>> 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?
> 
> The problem, even at the time, was not pps or bandwidth throughput of
> the NATs.  Rather, it was that NATs would not create new mappings
> quick enough and drop the STUN Binding Request.  This would be re-
> transmitted and make it through the NAT, but that retransmit was 
> obviously harmful for call setup times.  As all the connectivity
> checks are supposed to be sent from the same source address and
> port on the client, a new mapping is only necessary for NATs which
> have "address dependent mapping" or "address and port dependent
> mapping" behavior.
> 
> I just checked, and couldn't find a test of UDP mapping speed
> at http://nattest.net.in.tum.de/results.php, 
> draft-jennings-behave-test-results, or 
> http://eggert.org/papers/2010-imc-hgw-study.pdf.  Perhaps there
> are tests available somewhere else.
> 
Thanks for clearing that up.

>> And how does the different paths (IPv4, IPv6, multi
>> homed) impact the pacing? Could we do more in parallel without
>> overwhelm the NATs?
> 
> I'm sure we could.
> 
> We could also be more aggressive with STUN retransmissions, and
> less aggressive at trying new candidates.  That depends on our 
> confidence that the candidates are in the proper order, and if
> we can move a connection to a new candidate.  RTP can be moved
> pretty easily; TCP cannot.  Before ICE completes, we could move
> RTP sessions around without draft-wing-mmusic-ice-mobility.
> 
More agressive STUN retransmits would help speeding up things for RFLX 
candidates.

> It is probably worth backing up and enumerating the problem(s) we 
> have with ICE, and then deciding what we want to solve.
> 
Yes, you are right.

Keeping the number of connectivity checks at a minimum by removing the 
ones that will never work as this documents describes is probably what we
want from this document. 

>> 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.)
> 
> ICE was written before there was wide acceptance that the IPv6 path
> is sometimes broken.  Tweaking ICE to better accommodate that reality
> seems worthwhile.

Prioritising IPv6 over IPv4 is all about choosing from the valid_list and that is 
currently up to the different implementations to decide. Is it worthwhile having 
a separate document describing that?

.-.
Pål-Erik

> 
> -d
> 
> 
>> 
>> .-.
>> Pål-Erik
>> 
>> 
>>> --
>>> Jonathan Lennox
>>> jonathan@vidyo.com
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
> 