Subject: [Ice] unfreezing with disparate foundations

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 22 Feb 2016 21:34:16 -0700

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.

###