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

[Peter Thatcher <[e-mail]>]

Yeah, I was thinking of that edge case as well, which is why one version of
my proposed text was "send a local candidate or EOC", but EOC depends on
trickle-ice.

I think just basing this on the candidate information exchange is
sufficient and more simple, so I like it.

On Wed, Jul 10, 2019 at 4:09 PM Justin Uberti <[e-mail]> wrote:

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