Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? - discussion restart

[Christer Holmberg <[e-mail]>]

Hi,

>>> If there are remote candidates to check, then ICE should continue 
>>> checking them. Part of the problem is that when ICE is starting, it 
>>> is unclear if remote candidate have not been received yet, no usable remote
>>> candidates where received, or remote candidates are not going to be sent at all. 
>>> Also, checking remote candidates can end very quickly if remote candidates are 
>>> unreachable (fail immediately with ICMP remote address unreachable message).
>> Ok, let's assume we DO have remote candidates, and the timer expires. We discard the fact that the timer expires, and go on checking the remote candidates, as you suggested.
>>
>> Then, at some point we have checked all remote candidates, but we have NOT found successful pairs for all streams. So, since the timer already expired, we declare ICE failure.
>>
>> I thought the whole idea was to still wait for some time after we have tried all remote candidates, in case we will receive peer reflexive candidates, before we declare ICE failure.
>
> The scenario that I saw starting this debate was:
>
> - Offer/answer happens
>
> - Either some candidate pairs are formed, or no candidate pair are formed
>
> - All the candidate pairs formed can be discarded very quickly (because they are the wrong protocol, or non-routable addresses)
>
> - Failure is declared
>
> - ICE BIND requests from the other side arrive, giving peer-reflexive candidates, but ICE connection is already closed

I agree that is a valid use-case.

But, isn't that use-case just a version of the generic use-case: when we have no more remote candidates, we start a timer in order to wait for potential peer reflexive candidates? 

> The arrival time of the ICE BIND requests from the other side is independent of the length of the local candidate pair list, it depends on the length 
> of the remote candidate pair list, which is unknowable on the local side. The most likely time is "really fast".
>
>> But, as I said earlier, I am fine doing as you and others suggest. All I am saying is that the draft needs to describe what to do if the timer expires 
>> while there are still untested remote candidates. If the solution is to discard the timer expiration, then it needs to be documented.
>
> Saying that the timer and pair testing proceeds in parallel is all that needs to be said, I think.
> Declaring failure requires BOTH the timer to have expired AND testing of candidate pairs to complete.

No matter what solution we move forward with: we also need to define whether this applies to trickle.

For example, what if BOTH the timer has expired AND testing of currently available candidate pairs are complete, but trickle is still ongoing? Do we declare ICE failure, or do we discard the timer expiration?

Regards,

Christer