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

[Harald Alvestrand <[e-mail]>]

On 7/6/19 11:50 PM, Christer Holmberg wrote:
> 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

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.

The timer is a hack that can be applied by one side to fix the problem
for the 99% case.

A more architectural approach would be a way to pass (over the
signalling channel) a message saying "I have now sent all the BIND
requests I intend to send, if you haven't received any of them, please
give up now". But that requires both sides to update code and signalling
paths to be redesigned.

Let's deliver this document.

>
> Regards,
>
> Christer
>
>

-- 
Surveillance is pervasive. Go Dark.