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

[Roman Shpount <[e-mail]>]

On Thu, Apr 25, 2019 at 3:45 PM Nils Ohlmeier <[e-mail]> wrote:

> On Apr 25, 2019, at 11:25, Roman Shpount <[e-mail]> wrote:
>
> On Thu, Apr 25, 2019 at 2:17 PM Christer Holmberg <
> [e-mail]> wrote:
>
>> >The timer should start when the connectivity checks start by the remote
>> ICE agent. The timer is needed to make sure local candidate addresses
>> continue
>>
>> >to accept STUN binding requests for at least some minimal time, so
>> technically timer should start from the time remote ICE agent was informed
>> about
>>
>> >candidate addresses and started connectivity checks. There is some
>> signaling delay involved here, so it needs to accounted by the timer value.
>>
>>
>>
>> An agent doesn’t know when the peer agent will start - especially not the
>> offerer. If it sends an INVITE with its candidates, it may take a while
>> before the INVITE even reaches the peer agent, due to network services,
>> call forwarding etc etc etc.
>>
>>
>>
> This was actually one of the issues raised related to the timer start. The
> offerer can start the timer when it got the first remote candidate or end
> of candidates notification. Answerer is trickier, since there is no
> signaling indication when offerer actually got the answer. This is why I
> was thinking that an extra signaling message (
> https://github.com/cdh4u/draft-ice-pac/issues/11), indicating end of
> sending candidate checks might work better then a timer.
>
>
> It’s not a perfect solution, but in Firefox we do start the timer when we
> receive the first ICE candidate from the remote peer. Be it as part of the
> SDP or separate via trickle ICE. Note: this needs to happen though for
> valid and invalid candidates (e.g. if the ICE agent can’t handle mDNS
> candidates, but all candidates it receives are mDNS it needs to start the
> timer on the first candidate).
> We can not make this depend on end of candidates, because it’s quite
> likely today that an ICE agent will never receive end of candidates,
> especially with trickle ICE.
>

It is possible that agent will never receive any candidates since it is
technically legal to never send any candidates to the remote party when
doing trickle ICE. I guess timer does not start in this case so ICE will
wait before going into the failure state indefinitely.

I see ICE pac only as a not perfect workaround to cover for some corner
> cases. While solving this via an extra signaling message might be the
> better solution I think such a proposal should be done via a separate draft
> if desired/needed.
>

I understand the desire to limit the scope of this draft. From what I can
see there are 3 options:

1. Start timer when local ICE candidates collection was complete and at
least one ICE candidates was received from the remote via signaling message
or STUN bind request (timer starts when both conditions must be satisfied).
The problem with this is timer might never start and agent will wait
indefinitely.

2. Start timer when ICE candidates collection was complete or an ICE
candidates was received from the remote via signaling message or STUN bind
request (timer starts when either condition is satisfied). The problem here
is that if signaling messages are delivered too slowly, ICE nomination will
fail even when working candidate pair is potentially present.

3. Add some sort of extra signaling to indicate when ICE checks were
complete. In case of WebRTC this option can be implemented via option 1 and
some sort of application specific communications which will stop the
indefinite wait.

Based on this I would prefer going with option 1.
_____________
Roman Shpount