Subject: [Ice] Check lists and trickling

From: Justin Uberti <[email-masked]>
Date: Mon, 11 Apr 2016 21:43:05 -0700

In BA, I noted that unfreezing the candidate pairs associated with a
candidate that arrives for a media stream other than the first one will
cause all of that stream's candidate pairs to unfreeze, due to the rules in
S 5.8 (https://tools.ietf.org/html/rfc5245#section-5.8).

Someone mentioned that there was only a single check list, which would make
this a non-issue. However, I checked and indeed each stream is supposed to
have its own check list (ignoring bundle), as described in S 5.7 (
https://tools.ietf.org/html/rfc5245#section-5.7).

Therefore, while this concern of prematurely unfreezing check lists isn't
an issue for candidates that arrive for a different component (since they
share a check list), I think it is an issue for candidates that arrive for
different m= lines, and as such I'm not sure this new unfreezing behavior
is the correct solution in these cases.

---

From: Emil Ivov <[email-masked]>
Date: Tue, 12 Apr 2016 00:06:37 -0500

Hey Justin,

> S 5.8 (https://tools.ietf.org/html/rfc5245#section-5.8).

I may be missing your point but I don't think there's anything in 5245 (5.8
or elsewhere) that ever unfreezes all the pairs in a checklist in one go.

There's text that talks about activating a check list and there's text that
unfreezes an entire foundation actoss all check lists but neither of them
should be an issue with Peter's suggestion

I do agree with the rest of the mail here ... I just don't think any of it
is a problem.

Emil

> Someone mentioned that there was only a single check list, which would
> make this a non-issue. However, I checked and indeed each stream is
> supposed to have its own check list (ignoring bundle), as described in S
> 5.7 (https://tools.ietf.org/html/rfc5245#section-5.7).
>

-- 
sent from my mobile

---

From: Justin Uberti <[email-masked]>
Date: Tue, 12 Apr 2016 17:25:01 -0700

On Mon, Apr 11, 2016 at 10:06 PM, Emil Ivov <[email-masked]> wrote:

> I may be missing your point but I don't think there's anything in 5245
> (5.8 or elsewhere) that ever unfreezes all the pairs in a checklist in one
> go.
>
>
It's not that the checklist unfreezes all at once - it's that once you
unfreeze any pair in a checklist, the algo in 5.8 will necessarily unfreeze
the entire checklist in short order. That defeats the purpose of a frozen
checklist (i.e., you'll end up checking both streams in parallel).

> There's text that talks about activating a check list and there's text
> that unfreezes an entire foundation actoss all check lists but neither of
> them should be an issue with Peter's suggestion
>

---

From: Emil Ivov <[email-masked]>
Date: Tue, 12 Apr 2016 20:25:49 -0500

On Tuesday, 12 April 2016, Justin Uberti <[email-masked]> wrote:

>
>
> On Mon, Apr 11, 2016 at 10:06 PM, Emil Ivov <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> Hey Justin,
>>
>> On Monday, 11 April 2016, Justin Uberti <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>

I really don't think that's the case (and if you are saying what I think
you are saying then freezing would have been pointless even in vanilla ice)

Could you please point to the specific text that's bothering you?

The whole idea about unfreezing is that it happens along a foundation and
across lists. There are many cases where you would unfreeze some candidates
in a checklist (either because it was their turn or because their
entire foundation got unfrozen) but other pairs in the same check
list would remain frozen till ICE completes.

Emil

>> I do agree with the rest of the mail here ... I just don't think any of
>> it is a problem.
>>
>> Emil
>>
>>
>>> Therefore, while this concern of prematurely unfreezing check lists
>>> isn't an issue for candidates that arrive for a different component (since
>>> they share a check list), I think it is an issue for candidates that arrive
>>> for different m= lines, and as such I'm not sure this new unfreezing
>>> behavior is the correct solution in these cases.
>>>
>>
>>
>> --
>> sent from my mobile
>>
>
>

-- 
sent from my mobile

---

From: Justin Uberti <[email-masked]>
Date: Tue, 12 Apr 2016 22:04:34 -0700

reading 5.8, the algo indicates that for an active checklist, you check the
highest-prio pair in the waiting state, and if there is none, you check the
highest-prio frozen pair, thereby unfreezing it. This repeats on each timer
tick.

Basically, once a checklist is active, you will soon end up checking all of
its pairs. What am I missing?