Subject: [Ice] active / frozen check lists

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Jul 2017 08:48:39 -0600

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.

###

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.

###

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).

###

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.

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Jul 2017 15:11:12 +0000

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:
>
>###
>
>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 obviously would have to remove the term also from trickle, but would it affect the procedures?

###

>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?

###

>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.

###

>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?

Regards,

Christer

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Jul 2017 10:27:17 -0600

On 7/24/17 9:11 AM, Christer Holmberg wrote:
>> 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.
> 

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

> would it affect the procedures?

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

>> 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.
> 
> 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.

>> 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.
> 

Agreed.

Peter

---

From: Taylor Brandstetter <[email-masked]>
Date: Mon, 24 Jul 2017 16:19:03 -0700

Trickle ICE doesn't need to use the "active"/"frozen" state any more. I
brought this up in my review of draft-08:
https://mailarchive.ietf.org/arch/msg/ice/eiAyekLr4aTvFoDzUGhK3gyIsmY

Also, the reference to section 5.1.4 is just slightly outdated; section
5.1.4 previously referred to the "active" state, and now it doesn't.

So I don't think we have a problem. I agree with Christer's points.

On Mon, Jul 24, 2017 at 9:27 AM, Peter Saint-Andre <[email-masked]>
wrote:

> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Jul 2017 23:21:25 +0000

Hi,

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

5245bis already says that all pairs are initially set to frozen. I don't think you need to re-define it in trickle.

(We'll deal with the rest, if needed, once you've had time to look at it)

Regards,

Christer