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

[Peter Thatcher <[e-mail]>]

I agree.  The options you present seem reasonable and I think we should
move ahead with them.

On Mon, Jun 24, 2019 at 6:20 AM Harald Alvestrand <[e-mail]>
wrote:

> On 6/24/19 12:06 PM, Christer Holmberg wrote:
>
> Hi,
>
>
>
> Go for what? 😊
>
> I was noting the month of silence, and thinking that I should encoruage a
> decision to be taken - "analysis paralysis" is not a good thing!
>
>
>
> Regarding 1), eventhough it’s not my personal preference to start the
> timer when the first offer/answer is sent, I could live with it.
>
>
> It's a well defined time, and is observable by the entity that has to act
> when the timer expires, so I think it is much better than "undefined".
>
> That's my requirement :-)
>
>
>
>
> Regarding 2), however, I would really like some input on whether the
> duration should be independent of the number of streams, components etc.
>
> I think having a single number is preferable to having a complex number
> that could change over time (for instance, if we don't reset the timer when
> adding streams, then adding or removing streams after the timer started
> will lead to hard-to-define behavior).
>
>
> But my main concern is that we get this stuff done and get the basic timer
> mechanism into interoperable code - having a spec to implement from now is
> better than having a spec that has had slightly more discussion, but no
> fundamental changes, 6 months from now.
>
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From: *Harald Alvestrand <[e-mail]> <[e-mail]>
> *Date: *Sunday, 23 June 2019 at 9.08
> *To: *Christer Holmberg <[e-mail]>
> <[e-mail]>, Justin Uberti <[e-mail]>
> <[e-mail]>, Nils Ohlmeier <[e-mail]>
> <[e-mail]>
> *Cc: *Roman Shpount <[e-mail]> <[e-mail]>,
> "[e-mail]" <[e-mail]> <[e-mail]> <[e-mail]>
> *Subject: *Re: [Ice] ICE PAC: When to start the timer waiting for
> possible peer reflexive candidates? - discussion restart
>
>
>
> On 5/28/19 1:54 PM, Christer Holmberg wrote:
>
> Hi,
>
>
>
> We need to move forward with this.
>
>
>
> There are two main questions at the moment:
>
>
>
>    1. When does an endpoint start the timer ("minimum-time-to-run-ICE"
>    timer, based on previous discussions)?
>    2. What is the duration of the timer?
>
>
>
> Regarding 1), my understanding is that people suggest alternative c),
> which starts the timer when an endpoint has sent (in an offer or answer) at
> least one local candidate (or EOC).
>
>
>
>
>
> Regarding 2), it has been suggested that the duration would be the same as
> the max duration of a connectivity check transaction. Do we think that is
> enough, no matter how many media streams and components are used?
>
>
>
> Go for it. It is much better than having nothing.
>
>
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From: *Ice <[e-mail]> <[e-mail]> on behalf of
> Christer Holmberg <[e-mail]>
> <[e-mail]>
> *Date: *Friday, 3 May 2019 at 15.02
> *To: *Justin Uberti <[e-mail]> <[e-mail]>, Nils
> Ohlmeier <[e-mail]> <[e-mail]>
> *Cc: *Roman Shpount <[e-mail]> <[e-mail]>,
> "[e-mail]" <[e-mail]> <[e-mail]> <[e-mail]>
> *Subject: *Re: [Ice] ICE PAC: When to start the timer waiting for
> possible peer reflexive candidates?
>
>
>
> 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 <[e-mail]> <[e-mail]>
> *Date: *Thursday, 2 May 2019 at 22.28
> *To: *Nils Ohlmeier <[e-mail]> <[e-mail]>
> *Cc: *Christer Holmberg <[e-mail]>
> <[e-mail]>, Roman Shpount <[e-mail]>
> <[e-mail]>, "[e-mail]" <[e-mail]> <[e-mail]>
> <[e-mail]>
> *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 <[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
>
>
>
>
>
> _______________________________________________
>
> Ice mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/ice
>
>
>
> --
>
> Surveillance is pervasive. Go Dark.
>
>
> --
> Surveillance is pervasive. Go Dark.
>
> _______________________________________________
> Ice mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ice
>