Re: [Ice] active / frozen check lists

[Peter Saint-Andre <[e-mail]>]

On 7/24/17 9:11 AM, Christer Holmberg wrote:
> Hi Peter,
> 
> Thanks for your input! Please see inline.
> 
>> Apparently it was decided at IETF 99 to remove the terms "active
>> check list" and "frozen check list" from the core spec. These terms
>> are used in the trickle spec. For example:
>> 
>> ###
>> 
>> A Trickle ICE agent initially considers all check lists to be
>> frozen. It then inspects the first check list and attempts to
>> unfreeze all candidate pairs it has received so far that belong to
>>  the first component on the first media stream (i.e., the first
>> media stream that was reported to the ICE implementation from the
>> using application). If that first component of the first media
>> stream does not contain candidates for one or more of the currently
>> known pair foundations, and if candidate pairs already exist for
>> that foundation in one of the following components or media
>> streams, then the agent unfreezes the first of those candidate
>> pairs.
> 
> How would this change if we removed "frozen check list"?

We'd probably need to create a circumlocation such as "considers all
candidate pairs in all check lists to be frozen".

> We obviously would have to remove the term also from trickle, but
> would it affect the procedures?

I don't think so, just the terminology and text.

> ###
> 
>> The ICE specification [rfc5245bis], Section 5.1.4, requires that an
>> agent will terminate the timer for a triggered check in relation to
>> an active check list once the agent has exhausted all frozen pairs
>> in the check list. This will not work with Trickle ICE, because
>> more pairs will be added to the check list incrementally.
> 
> Do you refer to bullet 4) in section 5.1.4.2?
> 
> It is true that the non-trickle agent will eventually cease checking
> the check lists, but what does that have to do with the
> "active/frozen check list" terms?

Not much, I think. Later this week I will look at the text in detail.

> ###
> 
>> When a check list is set to Failed as described above, regular ICE
>> requires the agent to update all other check lists, placing one
>> pair from each check list into the Waiting >state - effectively
>> unfreezing all remaining check lists. However, under Trickle ICE
>> other check lists might still be empty at this point (because
>> candidates have not yet been >received), and following only the
>> rules from regular ICE would prevent the agent from unfreezing
>> those check lists (because the state of a check list depends on the
>> state of >the candidate pairs in that check list, but there are
>> none yet). Therefore a Trickle ICE agent needs to monitor whether a
>> check list is active or frozen independently of the >state of the
>> candidate pairs in the check list (since there might not be any
>> pairs yet). With regard to empty check lists, by default a Trickle
>> ICE agent MAY consider an empty >check list to be either active or
>> frozen. When a Trickle ICE agent considers an empty check list to
>> be frozen, during the candidate checking process it SHOULD change
>> the >check list to active if checking of another check list is
>> completely finished (i.e., if every pair in the other check list is
>> either Successful or Failed), if another check list has a >valid
>> candidate pair for all components, or if it adds a candidate pair
>> to the check list (because, in accordance with Section 8.1.1, when
>> inserting a new candidate pair into an >empty check list, the agent
>> sets the pair to a state of Waiting).
> 
> Why would an agent need to consider an empty list active or frozen?
> Can't the agent simply put the list in RUNNING state, even if it's
> empty, and whenever Ta triggers for that list the agent will check
> whether there are any candidates, and process them accordingly.

I will look at this later this week, as well.

> ###
> 
>> If we decide to continue with this approach, we'll need to look
>> more closely at the text in the trickle spec and make the necessary
>> wording changes.
> 
> Absolutely. But, based on your input, I don't identity any technical
> changes. Or have I missed them?

Agreed.

Peter