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

[Roman Shpount <[e-mail]>]

Hi,
On Mon, Apr 29, 2019 at 2:08 PM Justin Uberti <[e-mail]> wrote:

> On Mon, Apr 29, 2019 at 6:01 AM Christer Holmberg <
> [e-mail]> wrote:
>
>> In a non-trickle case, I think it would be very strange if the agent
>> didn’t get any candidates front the peer agent.
>>
>>
>> >I have just sent a message to the mmusic list regarding ice-sip-sdp and
>> offers with >no candidates. There is nothing that technically prohibits it
>> in RFC 5245, so I >thought it makes sense to add a note which explicitly
>> allows it in ice-sip-sdp.
>> >
>> >There is a valid use case for this, when client is behind NAT and it
>> would only >communicate with a server on public address. In such cases,
>> client does not need >to collect any candidates and simply send the offer.
>> Once it gets the answer from >the server with the public address, client
>> can send a STUN bind request to server >address using a local socket not
>> bound to any address, which will use default >route. There are multiple
>> benefits for implementing it this way, one of which >would be client
>> privacy.
>>
>> One option would then be to say that PAC only applies when an agent
>> actually has received some candidates from its peer.
>>
>> If an agent does NOT receive any candidates from the peer, it knows that
>> the only  candidates it will get are peer reflexive ones, and how long the
>> agent waits for those is an implementation issue.
>>
>> >Not sure that makes sense, that directly contradicts one of the examples
>> >in the actual PAC document.
>> >
>> >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.
>
>>
>> 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, 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.
>

There are two approaches that we can take:

First would be "practical" approach. If we assume that number of candidates
is reasonable, local candidate collection takes less then 1-2 seconds, TURN
candidates are returned in couple of seconds, and signaling delays are less
then a second or two, then entire candidate collection and delivery to
remote agent should take less then few seconds. In this case, if minimal
ice time to run is set to reasonably large time (like STUN bind request
timeout, which is 32 sec), then it would give both agents more then enough
time to send a several connectivity checks on all potential ICE candidate
pairs. In any case, if entire procedure would take much longer caller will
hung up and walk away.

Another approach would be "formally correct" approach, which would try to
make sure that ICE nomination succeeds when a valid candidate pair exists.
It will need to deal with large numbers of local candidates (50 candidates
with only candidate 40-something having access to public internet), slow
TURN candidate allocation which takes tens of seconds, and signaling delays
that introduce tens of seconds delays on candidate delivery. If you need to
deal with such setups, then ICE nomination should only fail after the last
STUN binding request from remote agent have failed. In case of ice-sip-sdp,
this will require an additional signaling message. In case of WebRTC this
would mean ICE would never fail unless it was explicitly told to stop by an
application.

We can also try to address something in between and start ICE minimal
time-out after last candidate was sent to the remote agent, but, in cases
with reasonable assumptions this should not make any difference, and in
extreme cases this would not be enough.

My preference would be to go with reasonable assumptions and start the
timer when the last local candidate (or indication that there are no local
candidates) was sent to the remote party.

Regards,
_____________
Roman Shpount