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

From: Bernard Aboba <[email-masked]>
Date: Mon, 8 Apr 2019 10:28:31 -0700

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"

---

From: Roman Shpount <[email-masked]>
Date: Mon, 8 Apr 2019 13:55:17 -0400

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 <[email-masked]>
wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>

---

From: Justin Uberti <[email-masked]>
Date: Mon, 15 Apr 2019 20:33:25 -0700

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 <[email-masked]> 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

---

From: Justin Uberti <[email-masked]>
Date: Thu, 18 Apr 2019 14:44:12 -0700

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

On Mon, Apr 15, 2019 at 8:33 PM Justin Uberti <[email-masked]> wrote:

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