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

[Harald Alvestrand <[e-mail]>]

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]> on behalf of Christer Holmberg
> <[e-mail]>
> *Date: *Friday, 3 May 2019 at 15.02
> *To: *Justin Uberti <[e-mail]>, Nils Ohlmeier
> <[e-mail]>
> *Cc: *Roman Shpount <[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]>
> *Date: *Thursday, 2 May 2019 at 22.28
> *To: *Nils Ohlmeier <[e-mail]>
> *Cc: *Christer Holmberg <[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?
>
>  
>
>  
>
>  
>
> On Thu, May 2, 2019 at 12:22 PM Nils Ohlmeier <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>      
>
>
>
>
>         On May 2, 2019, at 12:13, Justin Uberti <[e-mail]
>         <mailto:[e-mail]>> wrote:
>
>          
>
>          
>
>          
>
>         On Thu, May 2, 2019 at 10:07 AM Nils Ohlmeier
>         <[e-mail] <mailto:[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.