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

[Justin Uberti <[e-mail]>]

On Thu, May 2, 2019 at 3:42 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.
>
> If the agent does have working pairs, I think waiting for a additional
> peer reflexive candidates should only be a MAY. Using working pairs doesn't
> break anything, and waiting for peer reflexive candidates even if you have
> working pairs is just going to delay the nomination. But, if an agent only
> have "bad" working pairs (e.g., relayed) it MAY wait for additional peer
> reflexive candidates.
>
> What we want to do is to prevent that an agent declares failure too early
> if it does NOT have working candidates.
>

As stated earlier, I think that is only one part of the problem. But that's
largely separate from the discussion here about when to start the timer.

>
> ...
>
> >> 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.
>
> Correct.
>
> > 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.
>
> True.
>
> >I tend to lean towards a) as the simplest option.
>
> Keep in mind that RFC 8445 is generic, so we need to to define what we
> mean by "answer". I guess it means some kind of indication that makes the
> agent assume that the remote peer has been contacted. In ice-sip-sdp we can
> then map that to an SDP answer.
>
>
Yes, good point. We can start ICE processing (sending checks) as soon as we
have the remote username/password, so we could reframe it in those terms.