Subject: Re: [Ice] Check lists and trickling

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Jun 2016 13:34:07 +0000

Hi,

Just to clarify: I assume the referenced sections are in RFC 5245, right?
Because, they don’t exist in draft-5245bis :)

Regards,

Christer

On 24/05/16 00:43, "Ice on behalf of Emil Ivov" <[email-masked] on
behalf of [email-masked]> wrote:

>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
>
>_______________________________________________
>Ice mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ice

---

From: Emil Ivov <[email-masked]>
Date: Thu, 16 Jun 2016 06:59:29 -0700

Hey Christer,

Yes they are!

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Jun 2016 14:03:41 +0000

So, what are the corresponding 5245bis sections? :)

Regards,

Christer

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Jun 2016 20:43:48 -0600

> So, what are the corresponding 5245bis sections? :)

Seems easy to determine:

5245    ===>	5245bis

2.4		2.4
5.7.4		5.1.3.4
5.8		5.1.4
7.1.3.2.3	6.1.3.2.3

I haven't checked every line of text but it does appear that the text 
that Emil cites here has been copied across from 5245 to 5245bis.

/psa