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

[Christer Holmberg <[e-mail]>]

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.

...

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

Regards,

Christer