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 12:22 PM Nils Ohlmeier <[e-mail]> wrote:

>
>
> On May 2, 2019, at 12:13, Justin Uberti <[e-mail]> wrote:
>
>
>
> On Thu, May 2, 2019 at 10:07 AM Nils Ohlmeier <[e-mail]>
> wrote:
>
>>
>> >> 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).
>>
>> As we are mostly concerned about the remote side: 1) not providing us
>> with candidates, or 2) providing us with unusable candidates or 3)
>> providing us with candidates really late I don’t see how option c) would
>> help in any of these scenarios.
>> From my point of view we should choose either a) or b).
>>
>
> c) is just a clarification of a), in that you can't expect to receive
> prflx candidates until you've at least provided the other side with a
> candidate, so that may be the right time for the timer to start. I don't
> feel super strongly about this though.
>
>
> Ok. I hadn’t looked at it from that angle. So c) being a stronger a) I
> guess it would be okay.
>
> I guess my only concern is that in Firefox we stopped doing a) because it
> caused to many problems. With that in mind would it cause interop problems
> if we leave up to the implementor to choose to implement either b) or c)?
>

I'd be fine with that, but I'd want to describe what to watch out for. Can
you explain a bit more?

>
>
>> >> b) has a problem if the remote side doesn't send any candidates, which
>> we want to explicitly allow.
>> >
>> > True.
>>
> Just to make sure we are all on the same page: b) is only a problem in the
>> scenario where the remote side doesn’t send any candidates but also does
>> not send EOC.
>
>
>> The EOC should allow agents which explicitly don’t want to provide
>> candidate to get the timer started soon.
>> I think that leaves us with scenarios where the remote doesn’t provide
>> host candidates, and it’s reflexive or relay candidates take for ever
>> because of slow servers.
>>
>
> Correct, but we can't control which endpoints will send us an EOC or not.
> So that will always be a possibility.
>
>
> Fair enough.
>
>
>> >> 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.
>>
>> Good point. We basically treat the SDP answer here to be something like
>> an beginning of ICE, because we don’t have an explicit signal for that. I
>> think in SDP based worlds there is no need for an extra signal like that.
>> Not sure if other use cases of ICE would benefit from an explicit begin
>> signal.
>>
>
> The answer in some ways is an explicit begin signal, because it contains
> the username/password information needed to start ICE checks.
>
>
> Yeah I didn’t see your reply before hitting send on mine. Using the
> availability sounds like a good idea as the minimum gating function/signal.
>
> Best
>   Nils
>
>