Subject: [Ice] One more idea for how to resolve trickle ICE freezing behavior

From: Peter Thatcher <[email-masked]>
Date: Tue, 5 Apr 2016 13:26:04 -0700

(With chair hat off)

We still haven't figured out how to handle the freezing algorithm for
trickle ICE.  I'd be happy with saying "freezing is an optimization left to
the implementation" and leave it out of the spec, which avoids the issue
altogether.  But if that doesn't work, here's another idea:

Change the rule from

"attempts to unfreeze all candidates belonging to the first component on
the first media stream"

to

"attempts to unfreeze all candidates belonging to the first component on
the first media stream *of the candidates received so far*"

This means that if you receive a trickled candidate out of order according
to the "stream/component order", then its unfrozen.  When you receive a
trickled candidate later that is earlier in that order, then its unfrozen
also.   This avoids candidates being frozen indefinitely and at worse leads
to some candidates being unfrozen prematurely.

This has solves our problem with little downside.  I propose we use it and
remove the requirement that candidates be signaled in "media/component
order".

---

From: Emil Ivov <[email-masked]>
Date: Thu, 7 Apr 2016 12:21:06 -0500

On 5.04.16 г. 15:26, Peter Thatcher wrote:
> trickle ICE.  I'd be happy with saying "freezing is an optimization left
> to the implementation" and leave it out of the spec, which avoids the
> issue altogether.  But if that doesn't work, here's another idea:
>
> Change the rule from
>
> the first media stream /of the candidates received so far/"
>
>
> This means that if you receive a trickled candidate out of order
> according to the "stream/component order", then its unfrozen.  When you
> receive a trickled candidate later that is earlier in that order, then
> its unfrozen also.   This avoids candidates being frozen indefinitely
> and at worse leads to some candidates being unfrozen prematurely.
>
> This has solves our problem with little downside.  I propose we use it
> and remove the requirement that candidates be signaled in
> "media/component order".

An important aspect of ICE is the ability to do checks simultaneously 
which is necessary for things behind NATs to talk to each other.

Here's what trickle ICE says about this:

    Respecting the order in which lists have been reported to an ICE
    implementation, or in other words, the order in which they appear in
    SDP, is crucial to the frozen candidates algorithm and important when
    making sure that connectivity checks are performed simultaneously by
    both agents.

Following your suggestion and removing the above text would allow for a 
race condition where both sides are waiting for checks on different 
components/streams (i.e. ports) to succeed ... or essentially a deadlock.

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Thu, 7 Apr 2016 13:41:01 -0500

CORRECTION below!

> components/streams (i.e. ports) to succeed ... or essentially a deadlock.

I had misread the above and missed the second sentence which effectively 
removes the deadlock I mention. I also like this.