Subject: [Ice] Plan for handling trickle unfreezing

From: Peter Thatcher <[email-masked]>
Date: Wed, 20 Jul 2016 16:47:09 -0700

Justin brought up an issue with trickle unfreezing mixed with the 5245
"unfreeze the whole checklist" loop.   We've had some off-list discussions
about what we can do and we've come up with the following plan:

1.  Keep the "for every foundation, unfreeze the 'top' candidate you have
received so far" that we came up with in Buenos Aires.  It's already in the
trickle draft.

2.  Remove the "unfreeze the whole checklist" loop in 5245bis and replace
it with a new unfreezing rule to 5245bis: unfreeze the 'top' candidate for
every foundation.

This fixes the problem Justin brought up while maintaining the reason that
loop exists in the first place (as far as we can tell).  It also makes the
behavior consistent between non-trickle and trickle when candidates are
trickled in order.  It also makes 5245bis less complex.

#1 is already.

#2 will be discussed at the WG meeting during the time slot for 5245bis.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 20 Jul 2016 22:37:10 -0700

> received so far" that we came up with in Buenos Aires.  It's already in the

In this context, I assume 'top' == 'highest priority candidate for the
lowest-index m= line'?

> it with a new unfreezing rule to 5245bis: unfreeze the 'top' candidate
> for every foundation.
>

Is 'top' the same definition here? And do 'non-top' candidates only get
unfrozen when the 'top' one succeeds (or times out)?

If so, this seems sensible to me, as it preserves the general goal of
freezing (don't check things that are redundant) without adding extra delay.

> loop exists in the first place (as far as we can tell).  It also makes
> the behavior consistent between non-trickle and trickle when candidates are
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>
>

---

From: Emil Ivov <[email-masked]>
Date: Thu, 21 Jul 2016 07:53:28 +0200

Hey Justin,

Have a look at the attachment. The table there is probably the simplest (or
at least what I believe to be the simplest) way to represent the current
unfreezing algorithm of 5245. It's what Peter, Jonathan and I used to
support our discussion the other day and I am trying to make the case that
we should also use this representation to actually explain the algorithm in
5245bis.

So anyways, topmost therefore refers to the first candidate in a given
column. This is not necessarily the highest priority (priority mostly plays
in the ordering of foundations here) but the first pairs in any
component/stream to actually have a candidate pair for a given foundation.

Emil

On Thursday, 21 July 2016, Justin Uberti <[email-masked]> wrote:

>> This fixes the problem Justin brought up while maintaining the reason
>> that loop exists in the first place (as far as we can tell).  It also makes

---

From: Justin Uberti <[email-masked]>
Date: Wed, 20 Jul 2016 22:58:42 -0700

It's the highest priority of what you've got, right?

On Wed, Jul 20, 2016 at 10:53 PM, Emil Ivov <[email-masked]> wrote:

> Hey Justin,
>
> Have a look at the attachment. The table there is probably the simplest
> (or at least what I believe to be the simplest) way to represent the
> current unfreezing algorithm of 5245. It's what Peter, Jonathan and I used
> to support our discussion the other day and I am trying to make the case
> that we should also use this representation to actually explain the
> algorithm in 5245bis.
>
>>> 1.  Keep the "for every foundation, unfreeze the 'top' candidate you
>>> have received so far" that we came up with in Buenos Aires.  It's already
>>> in the trickle draft.
>>>
>>
>>> 2.  Remove the "unfreeze the whole checklist" loop in 5245bis and
>>> replace it with a new unfreezing rule to 5245bis: unfreeze the 'top'
>>> candidate for every foundation.
>>>
>>

---

From: Emil Ivov <[email-masked]>
Date: Thu, 21 Jul 2016 08:02:25 +0200

Well, technically speaking, yes, but only because the component ID is
part of the priority and all other factors (type and local preference)
will be the same for a given foundation.

Emil

On Thu, Jul 21, 2016 at 7:58 AM, Justin Uberti <[email-masked]> wrote:
>> (or at least what I believe to be the simplest) way to represent the current
>>>> have received so far" that we came up with in Buenos Aires.  It's already in
>>>> the trickle draft.
>>>
>>>

-- 
https://jitsi.org