Subject: Re: [Ice] Removing ICE frozen algorithm

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Jun 2016 20:47:31 -0600

On 4/1/16 12:26 PM, Ari Keränen wrote:
> All,
>
> What do you think about removing requirement for implementing frozen
> algorithm altogether from ICE-bis?

Hi Ari, do you mean removing the definition of the frozen algorithm, or 
saying that it is no longer mandatory-to-implement?

Peter

>
> This would obviously be a bigger change than what we originally
> planned for ICE-bis work, but based on the discussion so far there
> could be merit to it.
>
> Frozen algorithm is essentially an optimisation that allows one to
> not check high-priority candidate pairs that are likely not to work
> (e.g., host-host candidate for more than one stream/component). If
> agent has only one one stream and component, or uses RTCP-mux and
> Bundles all streams, frozen algorithm is not even used today. And
> current draft says you don't have to implement it for usages with
> only one stream and component. However, with multiple streams and/or
> components, it makes a difference.
>
> Apparently even if one endpoint does not implement the frozen
> algorithm, it would still interoperate with one that does. The checks
> would be slightly out of sync (one endpoint is doing checks for the
> candidate pairs that are frozen on the other), but if we reduce the
> STUN pacing value, this will be less of a problem since the NAT
> bindings should be alive and the whole process is likely to end in
> reasonable time. And if one cares about minimising amount of sent
> checks, one could still implement the algorithm.
>
> What is your opinion? Should we keep or remove the frozen algorithm
> requirement from ICE bis?
>
>
> Cheers, Ari
>
>> On 17 Mar 2016, at 16:32, Peter Thatcher <[email-masked]>
>> wrote:
>>
>>
>>
>> On Thu, Mar 17, 2016 at 12:22 PM, Christer Holmberg
>> <[email-masked]> wrote: Hi,
>>
>>>> I was thinking that we wouldn't care if candidates share the
>>>> same foundation or not - we deal with all candidates in the
>>>> same way.
>>>
>>> For trickle ICE specifically or for 5245bis?  ​
>>>
>>> I'm all for simplification and removing things we don't need.  I
>>> just want to understand the scope of which you are proposing we
>>> do so.
>>
>> I was thinking 5245bis: remove everything that talks about frozen
>> candidates.
>>
>>
>> Sounds good to me, if we feel like the downsides of not having
>> freezing are such that we can simply say "if you care about these
>> downsides, use rtcp-mux".  I'd like to hear from everyone else if
>> feels the same.​​
>>

---

From: Ari Keränen <[email-masked]>
Date: Thu, 23 Jun 2016 10:52:27 +0000

Hi Peter,

> On 23 Jun 2016, at 05:47, Peter Saint-Andre <[email-masked]> wrote:
> 
> Hi Ari, do you mean removing the definition of the frozen algorithm, or saying that it is no longer mandatory-to-implement?

If we would do this, I was thinking that it could be done e.g. by moving the definition to appendix to describe "legacy behavior". 

However, based on the latest discussion there wasn't anymore desire to do this change, so the frozen algorithm is still part of bis.

Cheers,
Ari

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 23 Jun 2016 07:01:49 -0700

I would support moving the algorithm to an Appendix and making it
non-mandatory to implement.  As you say, with BUNDLE/MUX becoming so widely
used, it is not needed in common situations.  Plus, it is possible to not
implement it and still interoperate.

On Fri, Apr 1, 2016 at 11:26 AM, Ari Keränen <[email-masked]>
wrote:

> This would obviously be a bigger change than what we originally planned
> for ICE-bis work, but based on the discussion so far there could be merit
> to it.
>
> Frozen algorithm is essentially an optimisation that allows one to not
> check high-priority candidate pairs that are likely not to work (e.g.,
> host-host candidate for more than one stream/component). If agent has only
> one one stream and component, or uses RTCP-mux and Bundles all streams,
> frozen algorithm is not even used today. And current draft says you don't
> have to implement it for usages with only one stream and component.
> However, with multiple streams and/or components, it makes a difference.
>
> Apparently even if one endpoint does not implement the frozen algorithm,
> it would still interoperate with one that does. The checks would be
> slightly out of sync (one endpoint is doing checks for the candidate pairs
> that are frozen on the other), but if we reduce the STUN pacing value, this
> will be less of a problem since the NAT bindings should be alive and the
> whole process is likely to end in reasonable time. And if one cares about
> minimising amount of sent checks, one could still implement the algorithm.
>
> > On 17 Mar 2016, at 16:32, Peter Thatcher <[email-masked]> wrote:
> >
> >
> >
> > On Thu, Mar 17, 2016 at 12:22 PM, Christer Holmberg <
> [email-masked]> wrote:
> > Hi,
> >
> > >> I was thinking that we wouldn't care if candidates share the same
> foundation or not - we deal with all candidates in the same way.
> > >
> > > I'm all for simplification and removing things we don't need.  I just
> want to understand the scope of which you are proposing we do so.
> >
> > Sounds good to me, if we feel like the downsides of not having freezing
> are such that we can simply say "if you care about these downsides, use
> rtcp-mux".  I'd like to hear from everyone else if feels the same.​​
> >
> >
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Jun 2016 14:00:17 +0000

Hi,

I am going to be away for two weeks, and the WG would have to make a formal decision to do the change, but anyone is welcome to create a pull request (or suggest text changes in an e-mail) for this at any time :)

Regards,

Christer

From: Bernard Aboba [mailto:[email-masked]]
Sent: 23 June 2016 17:02
To: Ari Keränen <[email-masked]>
Cc: [email-masked]; Peter Thatcher <[email-masked]>; Peter Saint-Andre <[email-masked]>; Christer Holmberg <[email-masked]>
Subject: Re: [Ice] Removing ICE frozen algorithm

I would support moving the algorithm to an Appendix and making it non-mandatory to implement.  As you say, with BUNDLE/MUX becoming so widely used, it is not needed in common situations.  Plus, it is possible to not implement it and still interoperate.

On Fri, Apr 1, 2016 at 11:26 AM, Ari Keränen <[email-masked]<mailto:[email-masked]>> wrote:
All,

What do you think about removing requirement for implementing frozen algorithm altogether from ICE-bis?

This would obviously be a bigger change than what we originally planned for ICE-bis work, but based on the discussion so far there could be merit to it.

Frozen algorithm is essentially an optimisation that allows one to not check high-priority candidate pairs that are likely not to work (e.g., host-host candidate for more than one stream/component). If agent has only one one stream and component, or uses RTCP-mux and Bundles all streams, frozen algorithm is not even used today. And current draft says you don't have to implement it for usages with only one stream and component. However, with multiple streams and/or components, it makes a difference.

Apparently even if one endpoint does not implement the frozen algorithm, it would still interoperate with one that does. The checks would be slightly out of sync (one endpoint is doing checks for the candidate pairs that are frozen on the other), but if we reduce the STUN pacing value, this will be less of a problem since the NAT bindings should be alive and the whole process is likely to end in reasonable time. And if one cares about minimising amount of sent checks, one could still implement the algorithm.

What is your opinion? Should we keep or remove the frozen algorithm requirement from ICE bis?

Cheers,
Ari

> On 17 Mar 2016, at 16:32, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>
> On Thu, Mar 17, 2016 at 12:22 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
> Hi,
>
> >> I was thinking that we wouldn't care if candidates share the same foundation or not - we deal with all candidates in the same way.
> >
> > I'm all for simplification and removing things we don't need.  I just want to understand the scope of which you are proposing we do so.
>
> I was thinking 5245bis: remove everything that talks about frozen candidates.
>
>
> Sounds good to me, if we feel like the downsides of not having freezing are such that we can simply say "if you care about these downsides, use rtcp-mux".  I'd like to hear from everyone else if feels the same.​​
>
>

_______________________________________________
Ice mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ice