Subject: [Ice] ICE trickle: Comment on section 8.1.1

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Mar 2018 17:11:14 +0000

Hi,

I was reading the rules in section 8.1.1 on how to set the pair state for trickled candidate pairs, and I think it can be simplified, as follows:

-          If there are no other pairs for the same foundation, set the state to Waiting   (covers Case #1)

-          If all other pairs for the same foundation are in either the Succeeded or Failed state, set the state to Waiting (covers Case #2)

-          If there are more than one pair for the same foundation in the Waiting state, set the state to Waiting (covers Case #3)

-          If there is exactly one pair for the same foundation in the Waiting state, set the state to Frozen (covers Case #4)

Am I missing some case?

Also, if you want to keep the tables, I think it would be good to indicate in the table which pair(s) were inserted, using some special character.

Currently the text says things like "two newly formed pairs were placed in column 5, rows 3 and 4", which is ok, but I also think it should be shown in the table.

Regards,

Christer

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Mar 2018 12:29:05 -0600

Hi Christer, thanks for the continued feedback...

On 3/24/18 11:11 AM, Christer Holmberg wrote:
> Hi,
> 
>  
> 
> I was reading the rules in section 8.1.1 on how to set the pair state
> for trickled candidate pairs, and I think it can be simplified, 

I'm hesitant to mess around with these rules, but let's discuss...

> as follows:

That covers Case #1 but it is more restrictive because it doesn't cover
the case where the new pair is not the only pair, just the topmost pair.

> -          If all other pairs for the same foundation are in either the
> Succeeded or Failed state, set the state to Waiting (covers Case #2)

That covers Case #2 but it is more permissive because it also covers the
case where the new pair is not immediately below the Succeeded pair and
the case where the new pair is above the Succeeded pair but not topmost.

> -          If there are more than one pair for the same foundation in
> the Waiting state, set the state to Waiting (covers Case #3)

That covers Case #3 but it is more permissive because it it also covers
the case where, say, two pairs succeeded and one pair is waiting.

> -          If there is exactly one pair for the same foundation in the
> Waiting state, set the state to Frozen (covers Case #4)
> 
>  
> 
> Am I missing some case?

Maybe? ;-)

I agree that the rules as written are complicated, but perhaps that's
unavoidable.

> Also, if you want to keep the tables, I think it would be good to
> indicate in the table which pair(s) were inserted, using some special
> character.
> 
> Currently the text says things like “two newly formed pairs were placed
> in column 5, rows 3 and 4”, which is ok, but I also think it should be
> shown in the table.

Good suggestion.

BTW, are you still reviewing the spec, or can we publish -18 once we're
done with the issues you've already sent to the list?

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Mar 2018 18:50:17 +0000

Hi,

I will take a second look at the rules in section 8.1.1. I just want to make sure they are aligned with the latest version of 5245bis.

Regards,

Christer

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: 27 March 2018 20:29
To: Christer Holmberg <[email-masked]>; [email-masked]
Subject: Re: [Ice] ICE trickle: Comment on section 8.1.1

> the state to Waiting   (covers Case #1)

That covers Case #1 but it is more restrictive because it doesn't cover the case where the new pair is not the only pair, just the topmost pair.

> -          If all other pairs for the same foundation are in either 
> the Succeeded or Failed state, set the state to Waiting (covers Case 
> #2)

That covers Case #2 but it is more permissive because it also covers the case where the new pair is not immediately below the Succeeded pair and the case where the new pair is above the Succeeded pair but not topmost.

> the Waiting state, set the state to Waiting (covers Case #3)

That covers Case #3 but it is more permissive because it it also covers the case where, say, two pairs succeeded and one pair is waiting.

Maybe? ;-)

I agree that the rules as written are complicated, but perhaps that's unavoidable.

> Currently the text says things like "two newly formed pairs were 
> placed in column 5, rows 3 and 4", which is ok, but I also think it 
> should be shown in the table.

Good suggestion.

BTW, are you still reviewing the spec, or can we publish -18 once we're done with the issues you've already sent to the list?

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Mar 2018 19:06:59 +0000

Hi,

>I'm hesitant to mess around with these rules, but let's discuss...

My issue is that I have a feeling you are still using old 5245bis concepts.

> That covers Case #1 but it is more restrictive because it doesn't cover the case where the new pair is not the only pair, just the topmost pair.

Not sure I understand "is not the only pair". If there are no other pairs for the same foundation, the new pair IS the only pair for that foundation :)
 
> That covers Case #2 but it is more permissive because it also covers the case where the new pair is not 
> immediately below the Succeeded pair and the case where the new pair is above the Succeeded pair but not topmost.

I don't understand the "immediately below" text etc.

According to the procedures in Section 7.2.5.3.3. of 5245bis, once a pair succeeds all Frozen pairs for the same foundation are set to Waiting.

And, in case #2 at least one pair has succeeded, which means the new pair should be set to Waiting.

> That covers Case #3 but it is more permissive because it it also covers the case where, say, two pairs succeeded and one pair is waiting.

Yes. I don't think that is a problem :)

Good suggestion.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Mar 2018 14:01:03 -0600

> My issue is that I have a feeling you are still using old 5245bis concepts.

Alignment is hard. I'll look at it again.

One thing that's bothering me about these rules is that they're written
about the diagrams (e.g., "top-most pair") and not about protocol
features (e.g., "the pair with the lowest component ID").

> Not sure I understand "is not the only pair". 

Let's say there are already two pairs for the 5th foundation:

   +-----------------+------+------+------+------+------+
   |                 |  f1  |  f2  |  f3  |  f4  |  f5  |
   +-----------------+------+------+------+------+------+
   | m1 (Audio.RTP)  |  W   |  W   |  W   |      |      |
   +-----------------+------+------+------+------+------+
   | m2 (Audio.RTCP) |  F   |  F   |  F   |  W   |      |
   +-----------------+------+------+------+------+------+
   | m3 (Video.RTP)  |  F   |      |      |      |  W   |
   +-----------------+------+------+------+------+------+
   | m4 (Video.RTCP) |  F   |      |      |      |  F   |
   +-----------------+------+------+------+------+------+

Now we add a new pair "X", which has a lower component ID than the other
pairs:

   +-----------------+------+------+------+------+------+
   |                 |  f1  |  f2  |  f3  |  f4  |  f5  |
   +-----------------+------+------+------+------+------+
   | m1 (Audio.RTP)  |  W   |  W   |  W   |      |      |
   +-----------------+------+------+------+------+------+
   | m2 (Audio.RTCP) |  F   |  F   |  F   |  W   | ^X^  |
   +-----------------+------+------+------+------+------+
   | m3 (Video.RTP)  |  F   |      |      |      |  W   |
   +-----------------+------+------+------+------+------+
   | m4 (Video.RTCP) |  F   |      |      |      |  F   |
   +-----------------+------+------+------+------+------+

That doesn't seem to be covered by your text.

(I realize this is a contrived or wrong example - we'd likely get
candidate pairs for both m1 and m2, or just m1. Imagine an example with
even more media streams and you get the picture.)

> If there are no other pairs for the same foundation, the new pair IS the only pair for that foundation :)
>  

I see your point.

> Yes. I don't think that is a problem :)

Ah, I see. The procedures you cite from Section 7.2.5.3.3. of 5245bis
actually cover both Case #2 and Case #3, don't they?

>>> Waiting state, set the state to Frozen (covers Case #4)

This is a fall-through case, isn't it? I'm not yet sure why we'd say
anything other than "in all other cases, set to Frozen"...

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Mar 2018 08:02:38 +0000

Hi,

>>> That covers Case #1 but it is more restrictive because it doesn't
>>>cover the case where the new pair is not the only pair, just the
>>>topmost pair.
>> 

It is not covered by case #1, because in case #1 there are no other pairs
in the foundation :)

The case above is covered by the following bullet I suggested:

"- If there is exactly one pair for the same foundation in the Waiting
state, set the state to Frozen (covers Case #4)²

So, in this case the state would be set to Frozen.

An alternative would be to change the m3 pair to Frozen, and set the new
pair to Waiting, but I think modifying the state of existing pairs would
be messy.

>>> immediately below the Succeeded pair and the case where the new pair
>>>is above the Succeeded pair but not topmost.
>> 
>> According to the procedures in Section 7.2.5.3.3. of 5245bis, once a
>>pair succeeds all Frozen pairs for the same foundation are set to
>>Waiting.
>> 
>>> That covers Case #3 but it is more permissive because it it also
>>>covers the case where, say, two pairs succeeded and one pair is waiting.
>> 

Correct. When at least one pair is Succeeded, all non-Failed pairs (Frozen
pairs and new trickled pairs) are set to Waiting. I think that would be a
simple approach.

>anything other than "in all other cases, set to Frozen"...

Sure, we could do that. The simpler the better :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Mar 2018 12:32:42 +0000

Hi,

I think the rules could be simplified in the following way:

- If there are at least one pair in Succeeded state, set the state of the
new pair to Waiting
- If there are two or more pairs in Waiting/In-Progress state, set the
state of the new pair to Waiting
- Otherwise set the state of the new pair to Frozen

Regards,

Christer

On 28/03/18 11:02, "Ice on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]> wrote:

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Mar 2018 09:36:45 -0600

> - If there are at least one pair in Succeeded state, set the state of the

Yes, that's consistent with §7.2.5.3.3 of 5245bis.

> state of the new pair to Waiting

Why "two or more"?

> - Otherwise set the state of the new pair to Frozen

I think that might do it. I will run through a bunch of scenarios
(offlist) to verify.

Please see one more comment below.

>> pair to Waiting, but I think modifying the state of existing pairs would

§6.1.2.6 of 5245bis states:

   5.  For each foundation, the agent sets the state of exactly one
       candidate pair to the Waiting state (unfreezing it).  The
       candidate pair to unfreeze is chosen by finding the first
       candidate pair (ordered by lowest component ID and then highest
       priority if component IDs are equal) in the first check list
       (according to the usage-defined check list set order) that has
       that foundation.

My inclination is to set the state of this "X" candidate pair to
Waiting, because it is now the candidate with the lowest component ID
(and highest prioritiy if the component IDs are equal) within this
foundation. However, if we proceeded in this way then we would have two
candidate pairs in the Waiting state within this foundation. That
doesn't seem like a problem, but I wanted to point it out.

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Mar 2018 16:51:23 +0000

Hi,

>> - If there are at least one pair in Succeeded state, set the state of 
>> the new pair to Waiting
>

Correct.

>> state of the new pair to Waiting

If there is only one (or no) pair in Waiting state, the check list set has just been initialized, which means there should be no more than one pair in the waiting state.
  
> I think that might do it. I will run through a bunch of scenarios

Please do :)

> Please see one more comment below.

...

>>>> Now we add a new pair "X", which has a lower component ID than the 
>>>> other pairs:
>>>>
>>>>
>>> It is not covered by case #1, because in case #1 there are no other 
>>> pairs in the foundation :)
>>>
>>> "- If there is exactly one pair for the same foundation in the 
>>> Waiting state, set the state to Frozen (covers Case #4)²
>>>
>>> An alternative would be to change the m3 pair to Frozen, and set the 
>>> new pair to Waiting, but I think modifying the state of existing 
>>> pairs would be messy.
>>
> My inclination is to set the state of this "X" candidate pair to Waiting, because it is now the candidate with the 
> lowest component ID (and highest prioritiy if the component IDs are equal) within this foundation. However, if we 
> proceeded in this way then we would have two candidate pairs in the Waiting state within this foundation. That 

Yes.

Another alternative would be to set the current pair in Waiting state to Frozen, since X has higher priority.

Regards,

Christer

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Mar 2018 11:54:30 -0600

> If there is only one (or no) pair in Waiting state, the check list set has just been initialized, which means there should be no more than one pair in the waiting state.

Is that true in the context of trickle? Couldn't a candidate pair
trickle in after initialization of the check list set?

> Another alternative would be to set the current pair in Waiting state to Frozen, since X has higher priority.

That seems preferable to me.

Peter

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 28 Mar 2018 11:05:34 -0700

Hi Christer,

Something that's lost by the simplified set of rules is the guarantee that
the "topmost" pair is always unfrozen. This ensures that the two ICE agents
always have at least one common pair unfrozen per foundation, even when
pairs are formed in a different order.

Suppose one agent forms pairs in order "A, B", and the other in the order
"B, A". With the simplified set of rules, one agent will unfreeze "A" and
the other "B", and connectivity checks may fail for each due to lack of
hole-punching. But with the "topmost" stipulation, one agent will unfreeze
"A" and the other both "A" and "B", so checks will succeed for "A" before
proceeding to "B".

This "topmost" rule wouldn't be necessary if candidate pairs were formed in
a deterministic order, which Section 16 guarantees. But I thought you were
planning to remove the ordering requirements of Section 16?
https://mailarchive.ietf.org/arch/msg/ice/XCquM6Gf-8bbG2ADXD4DNqePNK0

On Wed, Mar 28, 2018 at 10:54 AM, Peter Saint-Andre <[email-masked]>
wrote:

> > If there is only one (or no) pair in Waiting state, the check list set
> has just been initialized, which means there should be no more than one
> pair in the waiting state.
>
> >>>>>>>> -          If there are no other pairs for the same foundation,
> set
> >>>>>>>> the state to Waiting   (covers Case #1)
> >>>>>>>
> Waiting, because it is now the candidate with the
> >> lowest component ID (and highest prioritiy if the component IDs are
> equal) within this foundation. However, if we
> >> proceeded in this way then we would have two candidate pairs in the
> Waiting state within this foundation. That

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Mar 2018 18:27:45 +0000

Hi Taylor,

> Something that's lost by the simplified set of rules is the guarantee that the "topmost" pair is always unfrozen. 
> This ensures that the two ICE agents always have at least one common pair unfrozen per foundation, even when pairs are formed in a different order.

If you go to the bottom of the conversation, I think it is covered there :)

When a new pair is added, and if there is an existing pair in Waiting state, if the new pair has higher priority (i.e., it is "more topmost" than the current pair in Waiting state), the new pair is set to Waiting, and the current topmost is changed from Waiting to Frown.

Regards,

Christer

Suppose one agent forms pairs in order "A, B", and the other in the order "B, A". With the simplified set of rules, one agent will unfreeze "A" and the other "B", and connectivity checks may fail for each due to lack of hole-punching. But with the "topmost" stipulation, one agent will unfreeze "A" and the other both "A" and "B", so checks will succeed for "A" before proceeding to "B".

This "topmost" rule wouldn't be necessary if candidate pairs were formed in a deterministic order, which Section 16 guarantees. But I thought you were planning to remove the ordering requirements of Section 16? https://mailarchive.ietf.org/arch/msg/ice/XCquM6Gf-8bbG2ADXD4DNqePNK0

On Wed, Mar 28, 2018 at 10:54 AM, Peter Saint-Andre <[email-masked]> wrote:

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Mar 2018 18:37:05 +0000

Hi,

>>>> - If there are at least one pair in Succeeded state, set the state 
>>>> of the new pair to Waiting
>>>
>>>> - If there are two or more pairs in Waiting/In-Progress state, set 
>>>> the state of the new pair to Waiting
>>>
>>> Why "two or more"?
>> 
> > If there is only one (or no) pair in Waiting state, the check list set has just been initialized, which 
>> means there should be no more than one pair in the waiting state.
>
> Is that true in the context of trickle? Couldn't a candidate pair trickle in after initialization of the check list set?

Yes. But, there are two cases:

1. If there were pairs for the foundation at initialization, one pair (the topmost) was set to waiting.
2. The list was empty at initialization. In that case the first trickled pair automatically becomes topmost.

...

>>> candidate pairs in the Waiting state within this foundation. That doesn't seem 
>>> like a problem, but I wanted to point it out.
>> 
>> Yes.
>> 

Works for me too. That way, when there is only one pair in waiting state, we know it is the topmost at that given moment.

Regards,

Christer

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Mar 2018 13:55:44 -0600

> When a new pair is added, and if there is an existing pair in Waiting state, if the new pair has higher priority (i.e., it is "more topmost" than the current pair in Waiting state), the new pair is…

Yeah, I'm in a Frown state too, right now. ;-)

This gets messy to specify because handling of the topmost pair is a
proviso to another rule.

I might suggest the following:

1. If the newly formed pair has the lowest component ID of any candidate
pair for this foundation, set its state to Waiting.

2. If there is at least one pair in the Succeeded state for this
foundation, set the state of the newly formed pair to Waiting.

3. If there are two or more pairs in the Waiting or In-Progress state
for this foundation, set the state of the newly formed pair to Waiting.

[Question: when would #3 arise? Given 5245bis rules, it seems like we
would not have 2+ pairs in the Waiting or In-Progress state...]

4. Otherwise, set the state of the newly formed pair to Frozen.

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Mar 2018 20:01:37 +0000

Hi,

> 1. If the newly formed pair has the lowest component ID of any candidate pair for this foundation, set its state to Waiting.

Lowest component AND top-most, as many pairs will have the same component ID.
 
> 2. If there is at least one pair in the Succeeded state for this foundation, set the state of the newly formed pair to Waiting.

Yes.

> 3. If there are two or more pairs in the Waiting or In-Progress state for this foundation, set the state of the newly formed pair to Waiting.

Yes.

> [Question: when would #3 arise? Given 5245bis rules, it seems like we would not have 2+ pairs in the Waiting or In-Progress state...]

It happens when a pair has succeeded. After that all the pairs for the same foundation are set to Waiting.

Yes.

Regards,

Christer

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Mar 2018 14:07:22 -0600

> Lowest component AND top-most, as many pairs will have the same component ID.

Yes, I keep trying to get away from "topmost" because that's just a way
of describing things in terms of these mythical grids. But "pair with
the lowest component ID and, if there are candidates with the same
component ID value, also the highest priority" is long-winded.

> It happens when a pair has succeeded. After that all the pairs for the same foundation are set to Waiting.

But then isn't that covered by Rule #2?

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Mar 2018 20:17:07 +0000

Hi,

> Yes, I keep trying to get away from "topmost" because that's just a way of describing things in terms of 
> these mythical grids. But "pair with the lowest component ID and, if there are candidates with the same component ID 
> value, also the highest priority" is long-winded.

5245bis uses the following language for describing which pair is set to Waiting during initialization:

       "The candidate pair to unfreeze is chosen by finding the first
       candidate pair (ordered by lowest component ID and then highest
       priority if component IDs are equal) in the first check list
       (according to the usage-defined check list set order) that has
       that foundation."

I think we shall use the same terminology.

Pairs in different check lists, for the same foundation, may have the same component ID and priority, and therefore you need to also look at the order of the check list in which they occur.

> But then isn't that covered by Rule #2?

Correct. You are right.

Regards,

Christer

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Mar 2018 14:35:47 -0600

On 3/28/18 2:17 PM, Christer Holmberg wrote:
> I think we shall use the same terminology.>

Exactly. I'll reuse the 5245bis text with appropriate modifications for
trickle scenarios.

>> But then isn't that covered by Rule #2?

Simpler is better. :-)

I now have what I need to publish -18, which I will do later today.

Peter