Subject: Re: [Ice] Check lists and trickling

From: Peter Thatcher <[email-masked]>
Date: Sat, 16 Jul 2016 07:20:25 -0700

I went to make a PR to remove this inconsistency, but while doing so I
realized (I think) that's it's not an inconsistency after all, and is
actually the desired behavior.  That's because if two check lists have a
different number of candidates, then the only logic in the RFC to allow a
bigger check list to be completely unfrozen.

As far as trickle-ice goes, if we keep the rule of "unfreeze out-of-order
candidates", then that combined with "unfreeze the whole checklist"
behavior does mean that trickle ICE will have more limited freezing
behavior than non-trickle ICE.  However, given the limited value of
freezing when doing rtcp-mux and/or BUNDLE, and the fact that most trickle
ICE endpoints will be doing rtcp-mux and BUNDLE, I think losing some
freezing behavior value in certain edge cases is OK.

That said, I think it may be good to put something like the following in
the draft:

"When an ICE agent receives a trickled candidate out of order, it SHOULD
unfreeze that candidate after end-of-candidates is received.  It MAY
unfreeze the candidate earlier that if it expects that doing so will
establish a connection faster than keeping it frozen (such as when
end-of-candidates seems to be overly delayed)."

That way, we do keep the freezing behavior, at the cost of delaying the
unfreezing of the out-of-order candidate, at least to a point (until
end-of-candidates is received).  But we also allow the implementation the
flexibility to unfreeze earlier if it chooses.

On Mon, May 23, 2016 at 2:43 PM, Emil Ivov <[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: Sun, 17 Jul 2016 18:13:10 +0300

Hey Peter,

On Saturday, 16 July 2016, Peter Thatcher <[email-masked]> wrote:

> actually the desired behavior.
>
> I disagree. The current text is clearly contradictory. If it turns out
that one of its interpretations somehow appears to unblock certain
situations that to me is a side effect not an intention

>  That's because if two check lists have a different number of candidates,
> then the only logic in the RFC to allow a bigger check list to be
> completely unfrozen.
>

I think we specifically need text in 5245 bis to address the situation with
unequal number of foundations. The easiest way would be to just outlaw it.
If you need to do funky stiff like that: just negotiate a different
session. If not then just drop all candidates for the crippled foundation.

Now ... if you truly really absolutely want to have support for checklists
with different sizes we can add wording to the effect of: when unfreezing
the first pair in a checklist C as a result of successful checks in
preceding checklists P, the agent also unfreezes any pairs in C with
foundations that did not have pairs in P.

> freezing behavior value in certain edge cases is OK.

I haven't had a chance to comment on the whole "let's get rid of freezing"
topic but I think it's a bad idea. To begin with: BUNDLE is not an argument
for removing freezing as it simply doesn't use it. In other words: the fact
that everyone drives in a car today is not a reason to slaughter all horses
;).

For non-bundle cases, freezing still accelerates ICE processing and the
reasons for creating it are still there.

> end-of-candidates seems to be overly delayed)."

I like your original suggestion better, provided that we make it clear in
5245bis that unfreezing one pair does not and should not imply unfreezing
all pairs.

Emil

> On Mon, May 23, 2016 at 2:43 PM, Emil Ivov <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> Hey Justin,
>>
>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>> <mailto:[email-masked]
>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>> wrote:
>>>
>>>
>>>
>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>>     <mailto:[email-masked]
>>> <javascript:_e(%7B%7D,'cvml',[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:
>>>
>>>                 in S 5.8 (
>>> https://tools.ietf.org/html/rfc5245#section-5.8).
>>>
>>>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

-- 
sent from my mobile