Subject: Re: [Ice] Check lists and trickling

From: Emil Ivov <[email-masked]>
Date: Mon, 23 May 2016 16:43:31 -0500

Hey Justin,

Many apologies for missing this one! I hadn't seen it until I explicitly 
went to check my mailbox for updates on this thread.

So, I've gone over the text again and I can see what you mean. I think 
however that this is a contradiction in 5245 and that it goes against 
the intention of the freezing algorithm so we should probably fix it in 
5245bis.

Specifically, I think that section 5.7.4 and later section 7... are more 
accurate in the description of the freezing algorithm.

5.7.4 describes the initial situation:

  <quote>
The agent examines the check list for the first media stream.
For that media stream:
        *  For all pairs with the same foundation, it sets the
state of the pair with the lowest component ID to Waiting.
  </quote>

(note how this only unfreezes a single pair per foundation)

Then in 7.1.3.2.3 as we progress and update states we have the same 
foundation-based reasoning. Specifically as we validate pairs we will 
unfreeze certain foundations (and only foundations) of other frozen 
checklists:

  <quote>
7.1.3.2.3.
subpoint 1.  The agent changes the states for all other Frozen pairs for 
the same media stream *and same foundation* to Waiting.
  </quote>

Then once we validate an entire foundation of a given stream we will 
only unfreeze the same foundation (and only that foundation) of other 
streams:

  <quote>
7.1.3.2.3.
subpoint 2. If there is a pair in the valid list for every component of
    this media stream. The agent examines the check list for each
    other media stream in turn :
    * the state of all pairs in the check list whose foundation
    matches a pair in the valid list under consideration is set to
    Waiting
  </quote>

This also complies with the non-normative text in 2.4:

  <quote>
    The
    other candidate pairs are marked "frozen".  When the connectivity
    checks for a candidate pair succeed, the other candidate pairs with
    *the same foundation are unfrozen*.
  </quote>

And then:

  <quote>
    This *avoids* (Emil: not delays) repeated checking of
    components that are superficially more attractive but in fact are
    likely to fail.
  </quote>

So, as incredibly convoluted as this all may sound I do think that it 
makes more sense than the generic statement in 5.8.

If we were to accept the statement in 5.8 it would create race 
conditions that might even get candidates that should be frozen to be 
checked before unfrozen ones ... it would be a mess.

Do you see what I mean?

Emil

On 13.04.16 г. 0:04, Justin Uberti wrote:
> 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?
>
> On Tue, Apr 12, 2016 at 6:25 PM, Emil Ivov <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     On Tuesday, 12 April 2016, Justin Uberti <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>
>         On Mon, Apr 11, 2016 at 10:06 PM, Emil Ivov <[email-masked]> wrote:
>
>             Hey Justin,
>
>             On Monday, 11 April 2016, Justin Uberti <[email-masked]>
>             wrote:
>
>                 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).
>
>
>             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).
>
>
>     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
>
>
>
>             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).
>
>
>
>
>
>                 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
>
>

-- 
https://jitsi.org