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

[Justin Uberti <[e-mail]>]

On Sun, Jul 7, 2019 at 2:53 AM Christer Holmberg <
[e-mail]> 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
>
> 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?
>

Right, but that makes the waiting interval unnecessarily large. Really what
the timer is doing is setting a minimum amount of time for ICE to run, with
the idea that that minimum is as low as possible.

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

As noted above, the timer is just a minimum amount of time to run. If we
wouldn't have declared ICE failure without the timer, nothing changes that
fact.