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

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 May 2019 10:42:48 +0000

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

---

From: Justin Uberti <[email-masked]>
Date: Thu, 2 May 2019 09:57:04 -0700

On Thu, May 2, 2019 at 3:42 AM Christer Holmberg <
[email-masked]> wrote:

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

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

---

From: Nils Ohlmeier <[email-masked]>
Date: Thu, 2 May 2019 10:06:56 -0700

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

>> b) has a problem if the remote side doesn't send any candidates, which we want to explicitly allow. 

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.

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

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.

Best
  Nils

---

From: Justin Uberti <[email-masked]>
Date: Thu, 2 May 2019 12:13:19 -0700

On Thu, May 2, 2019 at 10:07 AM Nils Ohlmeier <[email-masked]> wrote:

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

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.

> we want to explicitly allow.
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.

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

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

---

From: Nils Ohlmeier <[email-masked]>
Date: Thu, 2 May 2019 12:22:02 -0700

> On May 2, 2019, at 12:13, Justin Uberti <[email-masked]> wrote:
> 
> 
> 
> On Thu, May 2, 2019 at 10:07 AM Nils Ohlmeier <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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)?

> Correct, but we can't control which endpoints will send us an EOC or not. So that will always be a possibility. 

Fair enough.

> 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

---

From: Justin Uberti <[email-masked]>
Date: Thu, 2 May 2019 12:28:33 -0700

On Thu, May 2, 2019 at 12:22 PM Nils Ohlmeier <[email-masked]> wrote:

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 May 2019 12:00:12 +0000

Hi,

I don’t think there will be any interoperability issues. At the end of the day PAC is only about how long to wait for candidates, so the worse thing that can happen is than an agent declares ICE failure too early.

And, no matter whether an agent knows that the peer supports PAC or not,  it should aim at sending it’s candidates to its peer as soon as possible, depending on whatever local policies. The agent should not delay sending candidates just because it assumes that the peer will anyway wait for them.

Regards,

Christer

From: Justin Uberti <[email-masked]>
Date: Thursday, 2 May 2019 at 22.28
To: Nils Ohlmeier <[email-masked]>
Cc: Christer Holmberg <[email-masked]>, Roman Shpount <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates?

On Thu, May 2, 2019 at 12:22 PM Nils Ohlmeier <[email-masked]<mailto:[email-masked]>> wrote:

On May 2, 2019, at 12:13, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

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

Fair enough.

Best
  Nils