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

[Justin Uberti <[e-mail]>]

On Tue, Apr 30, 2019 at 3:30 AM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> ...
>
> >>> Overall I think the Firefox approach makes the most sense - the PAC
> timer
> >>> starts when you have either a local or remote candidate.
> >>
> >> That would mean that PAC becomes a the-maximum-time-to-run-ICE timer.
> If that's what people want, fine.
> >
> > Maybe this is what you meant, but I think it's a
> "minimum-time-to-run-ICE" timer.
>
> I guess so, yes.
>
> However, as I said before, I think an agent shall still be allowed to stop
> earlier, and not be required to wait for peer reflexive candidates, if it
> already has working pairs.
>

Sure, this is not a point of contention, but a SHOULD-level directive may
make sense here.

>
> >> However, you can have a local candidate long before the remote peer
> gets it, so starting the timer once you
> >> have a candidate sounds strange to me. I think we should at least wait
> until the agent has sent the agent to the peer.
> >
> > This is an important observation - we don't want to start the timer
> until we think both us and the peer agent are running
> > ICE processing (e.g., if we just gathered candidates but didn't send an
> offer, we shouldn't start the timer). I'm not totally sure
> > what you meant above,
>
> That is one example: gather candidates but don't yet send an offer.
>
> > but one way to ensure we're in the right state would be to start the
> timer when both of the below are true:
> > 1) We have sent or received an answer.
> > 2) Local candidate gathering has completed (including the case when zero
> candidates have been gathered).
> >
> > #2 may not be strictly necessary, but gives us more flexibility in
> trickle cases if gathering takes a very long time (10+ seconds) for some
> reason.
>
> What about starting the timer after the agent has sent its last set of
> candidates? That would cover both trickle and non-trickle: in non-trickle
> there is only one set of candidates, and in trickle it doesn't matter how
> long it takes to provide all candidates since the timer doesn’t start until
> the last set of candidates have been sent?
>
>
That's basically the same thing I was proposing in 2), with the
clarification that the candidates were also actually transmitted. I do
think Nils' point is important though, i.e., if we have a bad server it
will take a very long time to decide on 'last set of candidates', which is
probably not helpful. As such I think the potential positions we can take
are:
a) Start the timer as soon as we have an answer, regardless of any
candidates.
b) a) + receipt of at least one remote candidate (or remote EOC). (This is
Nils' suggestion).
c) a) + sending at least one local candidate (or local EOC).

b) has a problem if the remote side doesn't send any candidates, which we
want to explicitly allow.

I tend to lean towards a) as the simplest option.