Subject: Re: [Ice] Removing ICE frozen algorithm

From: Cullen Jennings <[email-masked]>
Date: Sun, 10 Jul 2016 21:47:51 -0400

If you are not doing bundle, it looks to me like you still need it. 

> On Apr 1, 2016, at 2:26 PM, Ari Keränen <[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]> 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.​​
>> 
>> 
> 
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 11 Jul 2016 08:45:04 +0000

I also think it is needed for non bundeled scenarios.

But it could potentially be described in a separate draft. Just like we sort of is doing wit the renomination draft. Removing aggressive nomination to make the spec simpler, and adding a separate draft that adds a better set of functionality.

Pål-Erik
Sent from my iPhone

> On 11 Jul 2016, at 03:48, Cullen Jennings <[email-masked]> wrote:
> 
>