Subject: Re: [Ice] unfreezing with disparate foundations

From: Peter Thatcher <[email-masked]>
Date: Wed, 9 Mar 2016 11:25:19 -0800

Can we just say that trickle-ice must be used with rtcp-mux?  Then we don't
need to worry about this.   Non-muxed RTCP is becoming increasingly rare,
especially for WebRTC, where browsers will likely stop supporting it soon.

And what endpoint is going to implement trickle-ice but not rtcp-mux?

On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre <[email-masked]>
wrote:

> At IETF 94 we discussed potential changes to the unfreezing procedures for
> trickle when two components have different foundations. We didn't come up
> with a solution and redirected discussion to the list. Does anyone have a
> proposal to solve this impasse?
>
> Peter
>
> P.S. Here are the relevant notes from the IETF 94 minutes...
>
> ###
>
> If one component doesn't have the same foundation as another component,
> unfreezing logic doesn't work.
>
> Jonathan Lennox commented that trickle rules could enforce order, by
> providing components in order and maintain order.
>
> Emil Ivov: We shouldn't design at the mic. We already agreed that we
> trickle candidates in the order they'd be signaled, but if we want to
> change that, I'd be open.
>
> Jonathan: Trickling earlier doesn't gain anything if those pairs stay
> frozen. It just changes where the implementation burden is.
>
> Emil: Adding new states for components would make things complicated, so
> I'd prefer we keep the order.
>
> Peter (as individual): I think it's more burden on the sender side and
> less on the receiver side. It would also slow things down if signaling is
> slow. Plus, in WebRTC, we already have to deal with Javascript handing down
> remote candidates in the wrong order.
>
> Jonathan: We need signaling that means there are no candidates.
>
> Justin: How do we detect this?
>
> Jonathan: TURN allocation timed out, etc.
>
> Peter: Can we change the freezing algorithm to be more lax?
>
> Conclusion: Should take this to the mailing list what to do with
> unfreezing when one component doesn't have the same foundation as another.
> Signalling "no candidates for this component" is problematic. Delaying the
> signalling of other candidates is problematic. Still looking for a solution.
>
> ###
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 11 Mar 2016 19:50:36 -0700

On 3/9/16 12:25 PM, Peter Thatcher wrote:
> Can we just say that trickle-ice must be used with rtcp-mux?  Then we
> don't need to worry about this.   Non-muxed RTCP is becoming
> increasingly rare, especially for WebRTC, where browsers will likely
> stop supporting it soon.
>

Not because those two features are necessarily related, but because 
modern endpoints tend to implement both - correct?

Peter

>
>
>
>
>
> On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     At IETF 94 we discussed potential changes to the unfreezing
>     procedures for trickle when two components have different
>     foundations. We didn't come up with a solution and redirected
>     discussion to the list. Does anyone have a proposal to solve this
>     impasse?
>
>     Peter
>
>     If one component doesn't have the same foundation as another
>     component, unfreezing logic doesn't work.
>
>     trickle candidates in the order they'd be signaled, but if we want
>     to change that, I'd be open.
>
>     Jonathan: Trickling earlier doesn't gain anything if those pairs
>     stay frozen. It just changes where the implementation burden is.
>
>     Emil: Adding new states for components would make things
>     complicated, so I'd prefer we keep the order.
>
>     Peter (as individual): I think it's more burden on the sender side
>     and less on the receiver side. It would also slow things down if
>     signaling is slow. Plus, in WebRTC, we already have to deal with
>     Javascript handing down remote candidates in the wrong order.
>
>     unfreezing when one component doesn't have the same foundation as
>     another. Signalling "no candidates for this component" is
>     problematic. Delaying the signalling of other candidates is
>     problematic. Still looking for a solution.
>
>     ###
>
>     [email-masked] <mailto:[email-masked]>

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 14 Mar 2016 09:35:38 -0700

Correct.

On Fri, Mar 11, 2016 at 6:50 PM, Peter Saint-Andre <[email-masked]>
wrote:

> Not because those two features are necessarily related, but because modern
> endpoints tend to implement both - correct?
>
> Peter
>
>
>>
>>
>>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Mar 2016 14:52:09 +0000

Hi,

Stupid question: if the assumption is that implementers will move more and more towards rtcp-mux, do we need the freezing mechanism to begin with?

Regards,

Christer

From: Ice <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday 14 March 2016 at 18:35
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] unfreezing with disparate foundations

Correct.

On Fri, Mar 11, 2016 at 6:50 PM, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>> wrote:

Not because those two features are necessarily related, but because modern endpoints tend to implement both - correct?

Peter

On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Peter

    ###

    ###

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

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 17 Mar 2016 09:53:33 -0700

Are you suggesting that we just drop non-muxed RTCP from 5245bis
altogether, or are you suggested that we just leave non-muxed RTCP less
specified (and so it won't work as well, but oh well, use rtcp-mux if you
want things to work well) or something else?

On Thu, Mar 17, 2016 at 7:52 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> Stupid question: if the assumption is that implementers will move more and
> more towards rtcp-mux, do we need the freezing mechanism to begin with?
>
> Regards,
>
> Christer
>
> From: Ice <[email-masked]> on behalf of "[email-masked]" <
> [email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Mar 2016 17:08:56 +0000

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.

Based on what the browser folks say, browsers will anyway only support rtcp-mux, no matter if it's mandated by 5245bis or not.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Peter Thatcher<mailto:[email-masked]>
Sent: ‎17/‎03/‎2016 18:54
To: Christer Holmberg<mailto:[email-masked]>
Cc: Peter Saint-Andre<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ice] unfreezing with disparate foundations

Are you suggesting that we just drop non-muxed RTCP from 5245bis altogether, or are you suggested that we just leave non-muxed RTCP less specified (and so it won't work as well, but oh well, use rtcp-mux if you want things to work well) or something else?

On Thu, Mar 17, 2016 at 7:52 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Correct.

Peter

    Peter

    ###

    ###

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 17 Mar 2016 11:09:20 -0700

On Thu, Mar 17, 2016 at 10:08 AM, 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.

>
> Based on what the browser folks say, browsers will anyway only support
> rtcp-mux, no matter if it's mandated by 5245bis or not.
>
> Regards,
>
> Christer
>
>
>
> ------------------------------
> From: Peter Thatcher <[email-masked]>
> To: Christer Holmberg <[email-masked]>
> Cc: Peter Saint-Andre <[email-masked]>; [email-masked]
>
>> Stupid question: if the assumption is that implementers will move more
>> and more towards rtcp-mux, do we need the freezing mechanism to begin with?
>>
>> Regards,
>>
>> Christer
>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Mar 2016 19:22:11 +0000

Hi,

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

Regards,

Christer

Sent from my Windows Phone
________________________________________
From: Peter Thatcher
Sent: ‎17/‎03/‎2016 18:54
To: Christer Holmberg
Cc: Peter Saint-Andre; [email-masked]

On Thu, Mar 17, 2016 at 7:52 AM, Christer Holmberg <[email-masked]> wrote:
Hi,

Regards,

Christer

From: Ice <[email-masked]> on behalf of "[email-masked]" <[email-masked]>

Correct.

On Fri, Mar 11, 2016 at 6:50 PM, Peter Saint-Andre <[email-masked]> wrote:

Peter

    Peter

    ###

    ###

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 17 Mar 2016 12:32:58 -0700

On Thu, Mar 17, 2016 at 12:22 PM, Christer Holmberg <
[email-masked]> wrote:

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