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

[Justin Uberti <[e-mail]>]

yes, a candidate

On Wed, Jul 10, 2019 at 11:19 PM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
>
>
> What do you mean by ”single IP from the remote side”? A candidate?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From: *Justin Uberti <[e-mail]>
> *Date: *Thursday, 11 July 2019 at 2.09
> *To: *Christer Holmberg <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, Harald Alvestrand <
> [e-mail]>, Nils Ohlmeier <[e-mail]>, Roman
> Shpount <[e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *Re: [Ice] ICE PAC: When to start the timer waiting for
> possible peer reflexive candidates? - discussion restart
>
>
>
> When writing up this text, I realized there are edge cases where you might
> want to discover prflx candidates even if you didn't send any candidates
> (e.g., you don't send any candidates, you get a single IP from the remote
> side, and when you check it, you get a response back from a different IP).
>
>
>
> Ergo, I think we should start the timer as soon as we have local and
> remote ICE credentials, regardless of whether or not we send a candidate.
>
>
>
> On Wed, Jul 3, 2019 at 9:22 PM Justin Uberti <[e-mail]> wrote:
>
> For #1, I don't think the proposed solution is correct. The "alternative
> c)" that I proposed is to "Start the timer as soon as we have received a
> remote offer or answer and have also sent a local candidate to the remote
> side", which is different than what is mentioned in the OP.
>
>
>
> The rationale for this is:
>
> A) we can't start ICE processing (checks) until we get a remote
> offer/answer with ICE credentials
>
> B) we can't receive an incoming check that could create a prflx candidate
> unless we sent a candidate to the remote side
>
>
>
> Tracking this issue in https://github.com/cdh4u/draft-ice-pac/issues/12
> <https://protect2.fireeye.com/url?k=fa812fa0-a60b0d76-fa816f3b-0cc47ad93dcc-14ecb4925c17821c&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-ice-pac%2Fissues%2F12>
> .
>
>
>
> For #2, I agree we should use the "max duration of a connectivity check
> transaction". I think this value will work just fine in real world
> scenarios. And if the timer expires before we have tested all pairs (this
> can certainly happen, in the case of two hosts with no connectivity to each
> other), we just resume existing ICE processing, and fail when everything
> moves to the failed state (i.e., every pair has timed out). The timer is
> simply there to prevent premature failures.
>
>
>
> Tracking in https://github.com/cdh4u/draft-ice-pac/issues/13
> <https://protect2.fireeye.com/url?k=560d1e46-0a873c90-560d5edd-0cc47ad93dcc-dad442e58bc4db30&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-ice-pac%2Fissues%2F13>
>
>
>
>
>
> On Wed, Jul 3, 2019 at 1:02 PM Christer Holmberg <
> [e-mail]> wrote:
>
> So, what timer value do people want?
>
>
>
> And, assuming the timer value is not going to be based on the number of
> streams, what do we do if the timer expires before we have tested all pairs
> for all streams? I think we need to specify that.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Peter Thatcher <[e-mail]>
> *Sent:* 02 July 2019 03:56
> *To:* Harald Alvestrand <[e-mail]>
> *Cc:* Christer Holmberg <[e-mail]>; Justin Uberti <
> [e-mail]>; Nils Ohlmeier <[e-mail]>; Roman Shpount
> <[e-mail]>; [e-mail]
> *Subject:* Re: [Ice] ICE PAC: When to start the timer waiting for
> possible peer reflexive candidates? - discussion restart
>
>
>
> 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
>
>