Re: [Ice] Review of draft-holmberg-ice-pac-01

Tracking this in https://github.com/cdh4u/draft-ice-pac/issues/7

On Mon, Apr 15, 2019 at 8:33 PM Justin Uberti <juberti@google.com> wrote:

> I don't think there's an easy way to use a newly discovered prflx
> candidate, given the rules about changing the selected pair after ICE has
> completed, but I think this implies that one shouldn't be too hasty to
> declare ICE completion either.
>
> Since some implementations may malfunction if they don't get a
> USE-CANDIDATE quickly, I am not sure if we can wait the full STUN timeout
> interval, but perhaps a somewhat shorter delay (e.g. a few seconds) could
> be recommended before sending USE-CANDIDATE.
>
> On Mon, Apr 8, 2019 at 10:55 AM Roman Shpount <roman@telurix.com> wrote:
>
>> Bernard,
>>
>> The big issue here is when ICE agent can release candidates. Normally,
>> when ICE nomination completes, unused ICE candidates, such as unused local
>> interfaces or TURN candidates are released after a short (3 second)
>> timeout. Because of this, running new ICE connectivity checks without ICE
>> re-start (which means new ufrag and pwd, signaling exchange and allowing
>> remote to gather new candidates) is likely not going to succeed. For
>> instance, one party can move from IPv4 to IPv6 network, but the other party
>> would already release its lPv6 candidate, which will cause all connectivity
>> checks to fail.  Also, peer reflexive candidates are not gathered after ICE
>> nomination is complete. Changing this will not be a backwards compatible
>> change. This is completely different from the use case discussed in ice-pac
>> draft, which deals with ICE nomination failing before peer reflexive
>> candidates are discovered. All that ice-pac draft does is specifying a
>> delay for ICE nomination completion in the absence of remote candidates,
>> not collecting remote candidates after nomination is complete.
>>
>> Regards,
>> _____________
>> Roman Shpount
>>
>>
>> On Mon, Apr 8, 2019 at 1:28 PM Bernard Aboba <bernard.aboba@gmail.com>
>> wrote:
>>
>>> A question has arisen recently about the behavior with respect to peer
>>> reflexive candidates discovered *after* ICE completion:
>>> https://github.com/w3c/webrtc-nv-use-cases/issues/10
>>>
>>> draft-holmberg-ice-pac doesn't relate to that question, but I'm
>>> wondering whether we might also see significant differences in
>>> implementation behavior there as well. RFC 8445 appears to require an ICE
>>> restart to be able to use a newly discovered peer reflexive candidate after
>>> ICE completion because it represents a change in the destination, but I'm
>>> wondering if there are implementations that enable a peer reflexive
>>> candidate to be used anyway.
>>>
>>> Christer Holmberg said:
>>>
>>> "Hi,
>>>
>>> Doing an ICE restart means you have to collect and exchange candidates again. Of course one can do that once ICE failure has been declared, and nothing prevents one from doing an ICE restart after that if one thinks the result will be different. But, the focus of the draft is not to declare ICE failure while working candidates may still arrive.
>>>
>>> Having said that, one should of course not wait forever for the peer reflexive candidates. The draft will not mandate a specific time value, but there probably will be a little more text about things to take into consideration when determining how long to wait.
>>>
>>> Regards,
>>>
>>>
>>> Christer"
>>> _______________________________________________
>>> Ice mailing list
>>> Ice@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ice
>>>
>> _______________________________________________
>> Ice mailing list
>> Ice@ietf.org
>> https://www.ietf.org/mailman/listinfo/ice
>>
>