Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 2 May 2017 14:01:53 -0600

On 4/9/17 4:52 PM, Peter Saint-Andre wrote:
> On 3/30/17 11:28 PM, Taylor Brandstetter wrote:
>> I reviewed Trickle ICE, and overall I think it's in pretty good shape.
>> The main remaining areas I believe could be improved are:
>>
>>  1. Using terminology that's too SDP-specific. This has been improved a
>>     lot since I last reviewed, but in my opinion it could still be made
>>     a bit better. If it used the same sort of terminology as ICEbis
>>     ("convey the ICE parameters" as opposed to "send an ICE
>>     description"), I'd be happy. But I may be nitpicking too much.
> 
> Consistency with rfc5245bis seems like a good idea.
> 
>>  2. The unfreezing logic still doesn't seem perfect. If there are people
>>     who still feel it's important, I'd be glad to explain the issues as
>>     I see them further and work on fixing them. Though, I'm fine with
>>     saying "what we have is good enough." The current unfreezing logic
>>     at least now clearly ensures that one candidate per foundation is
>>     always unfrozen.
> 
> I feel we're at the "good enough" stage, but if you have significant
> concerns then let's hear you out.
> 
>> Here are the individual issues I found:
>>
>>   * In the terminology section:
>>       o The definition of "ICE description" refers to SDP attributes
>>         like "ice-ufrag" by name. This should be changed to just say
>>         "username fragment" (for instance) and not rely on SDP terminology.
> 
> Agreed.
> 
>>       o Also, in my opinion, using the terms "description," "session"
>>         and even "attribute" ties this too much to SDP. ICEbis uses the
>>         phrase "candidate information" to refer to the collection of
>>         information that's signaled; can Trickle ICE refer to this, and
>>         use similar terminology? ICEbis also says "parameter" rather
>>         than "attribute".
> 
> Fine with me, except for "session" (which is used in 5245bis and per
> list discussion will be defined in the next version of 5245bis).
> 
>>       o Related to the above: the concept of "sending an ICE
>>         description," used in many places, sounds too much like "sending
>>         an SDP offer" to me. ICEbis uses terminology like "the following
>>         parameters and their data types need to be conveyed as a part of
>>         the candidate exchange process," which is much less prescriptive
>>         of an offer/answer or message-based signaling protocol. Again;
>>         could Trickle ICE use similar terminology?
> 
> I'll change it everywhere to "convey candidate information".

Emil and I just had a co-author sync on the spec because I made the
changes in -09 without consultation. :-) He mentioned that, in the
trickle context, the phrase "convey initial candidate information"
(instead of the old "send initial ICE description") is confusing to
implementers because the agent isn't necessarily sending any candidates
at the beginning (i.e., the initial ICE description can be empty, and
it's weird to say "the act of conveying initial candidate information
might not actually convey any candidates!"). We'd prefer to revert to
the older phrasing unless there are strenuous objections. Alternative
suggestions are of course welcome.

Peter

---

From: Emil Ivov <[email-masked]>
Date: Tue, 2 May 2017 16:47:42 -0500

Hey,

Apologies for coming in a bit late on this.

On 4/18/17 8:44 PM, Taylor Brandstetter wrote:
>     Taylor, would you mind spelling this out a bit more fully and point to
>     discrepancies between the text of 5245bis and the text of the Trickle
>     spec? I'm sure I'm missing something, but I don't yet see the truth of
>     your statement that "only the topmost remaining pair in each foundation
>     is guaranteed to be unfrozen".
>
>
> Sure; let me try to give an example.
>
> Suppose I have three media streams, and one foundation (let's keep it
> simple). I'll represent the states like this for brevity: "SWFFFF",
> where "S" is "succeeded", "W" is "waiting", and "F" is "frozen". And
> they're ordered in the same way as the rows in your table above.
>
> With non-trickle ICE, here's what would typically happen:
>
>  1. Only the RTP candidate pair for the first media stream is unfrozen
>     initially.
>     State: WFFFFF
>  2. Check succeeds for RTP candidate pair. RTCP pair unfrozen.
>     State: SWFFFF
>  3. Check succeeds for RTCP pair. /All/ the other pairs with the same
>     foundation are now unfrozen.
>     State: SSWWWW
>
> With trickle ICE, here's what could happen:
>
>  1. Candidates for the first media stream are trickled in. Starts out
>     just like normal ICE.
>     State: WF
>  2. Checks for both pairs succeed. Still waiting for candidates for
>     other media streams.
>     State: SS
>  3. Candidates for the other media streams arrive, and pairs are formed.
>     The topmost pair is set to waiting, but not the others.
>     State: SSWFFF
>
> So, where normal ICE ensures that once a foundation is proven to work
> (for both components of a media stream), all other pairs with that
> foundation are unfrozen, trickle ICE only guarantees that one of them is.

So yes, I agree this is a difference with 5245bis, but it's intentional. 
I see this in part as a simplification (I don't think it is a meaningful 
optimization even for 5245bis) but more specifically I am reluctant to 
deal with situations where the candidate matrix is asymmetric for 
whatever weird reason and one side is trying checks for M2F3 but the 
other isn't responding because M2F3 is blocked after a hole in M2F2 and 
it is not supposed to be unfrozen yet. Or something along those lines.

So, unless someone has a great reason for why we'd need an entire stream 
to succeed before unfreezing the foundation, I'd rather we kept things 
as they are.

Emil

>
> On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     [areas of seeming agreement elided]
>
>     >   * In section 8.1.1: In general I like the improvements that have
>     been
>     >     made. However:
>     >       o The rules for how a new pair gets either a "Waiting" or
>     "Frozen"
>     >         state don't completely match standard ICE; at least the part
>     >         where when one "media stream" completes, pairs from other media
>     >         streams with matching foundations are unfrozen. With the current
>     >         rules in section 8.1.1, only the topmost remaining pair in each
>     >         foundation is guaranteed to be unfrozen. Is this difference
>     >         acceptable? If it is, we should at least acknowledge it, and not
>     >         give the wrong impression by saying "Trickle ICE preserves all
>     >         of [the standard ICE] rules."
>
>     Taylor, would you mind spelling this out a bit more fully and point to
>     discrepancies between the text of 5245bis and the text of the Trickle
>     spec? I'm sure I'm missing something, but I don't yet see the truth of
>     your statement that "only the topmost remaining pair in each foundation
>     is guaranteed to be unfrozen".
>
>     In particular, your statement doesn't seem to match the rules defined in
>     the Trickle spec. I've tried to spell them out in greater detail (with
>     examples) in the following proposed text.
>
>     ###
>
>
>     8.1.1.  Inserting a New Pair in a Check List
>
>        Consider the following tabular representation of all checklists in an
>        agent:
>
>
>        +-----------------+------+------+------+------+------+
>        |                 |  f1  |  f2  |  f3  |  f4  |  f5  |
>        +-----------------+------+------+------+------+------+
>        | m1 (Audio.RTP)  |  cp  |  cp  |  cp  |      |      |
>        +-----------------+------+------+------+------+------+
>        | m2 (Audio.RTCP) |  cp  |  cp  |  cp  |  cp  |      |
>        +-----------------+------+------+------+------+------+
>        | m3 (Video.RTP)  |  cp  |      |      |      |  cp  |
>        +-----------------+------+------+------+------+------+
>        | m4 (Video.RTCP) |  cp  |      |      |      |  cp  |
>        +-----------------+------+------+------+------+------+
>
>
>                        Figure 1: Example of Check List State
>
>        Each row in the table represents a component for a given media stream
>        (e.g., m1 and m2 might be the RTP and RTCP components for audio).
>        Each column represents one foundation.  Each cell represents one
>        candidate pair.
>
>        When an agent commences ICE processing, in accordance with
>        Section 5.1.3.6 of [rfc5245bis] it will unfreeze (i.e., place in the
>        Waiting state) the topmost candidate pair in every column (i.e., the
>        pair with the lowest component ID).  This state is shown in the
>        following table, with candidate pairs in the Waiting state marked by
>        "w-cp".
>
>
>        +-----------------+------+------+------+------+------+
>        |                 |  f1  |  f2  |  f3  |  f4  |  f5  |
>        +-----------------+------+------+------+------+------+
>        | m1 (Audio.RTP)  | w-cp | w-cp | w-cp |      |      |
>        +-----------------+------+------+------+------+------+
>        | m2 (Audio.RTCP) |  cp  |  cp  |  cp  | w-cp |      |
>        +-----------------+------+------+------+------+------+
>        | m3 (Video.RTP)  |  cp  |      |      |      | w-cp |
>        +-----------------+------+------+------+------+------+
>        | m4 (Video.RTCP) |  cp  |      |      |      |  cp  |
>        +-----------------+------+------+------+------+------+
>
>
>                         Figure 2: Initial Check List State
>
>        Then, as the checks proceed (see Section 6.1.2.4.2.3 of
>        [rfc5245bis]), for each pair that enters the Succeeded state (denoted
>        here by "s-cp"), the agent will unfreeze all pairs for the same media
>        stream and foundation (e.g., if the pair in column 1, row 1 succeeds
>        then the agent will unfreeze the pair in column 1, row 2).
>
>
>        +-----------------+------+------+------+------+------+
>        |                 |  f1  |  f2  |  f3  |  f4  |  f5  |
>        +-----------------+------+------+------+------+------+
>        | m1 (Audio.RTP)  | s-cp | w-cp | w-cp |      |      |
>        +-----------------+------+------+------+------+------+
>        | m2 (Audio.RTCP) | w-cp |  cp  |  cp  | w-cp |      |
>        +-----------------+------+------+------+------+------+
>        | m3 (Video.RTP)  |  cp  |      |      |      | w-cp |
>        +-----------------+------+------+------+------+------+
>        | m4 (Video.RTCP) |  cp  |      |      |      |  cp  |
>        +-----------------+------+------+------+------+------+
>
>
>                  Figure 3: Check List State after Succeeded Check
>
>        ICE also specifies that, if all the pairs in a media stream for one
>        foundation are unfrozen (e.g., column 1, rows 1 and 2 representing
>        both components for the audio stream), then all of the candidate
>        pairs in the entire column are unfrozen (e.g., column 1, rows 3 and
>        4).
>
>
>
>        +-----------------+------+------+------+------+------+
>        |                 |  f1  |  f2  |  f3  |  f4  |  f5  |
>        +-----------------+------+------+------+------+------+
>        | m1 (Audio.RTP)  | s-cp | w-cp | w-cp |      |      |
>        +-----------------+------+------+------+------+------+
>        | m2 (Audio.RTCP) | w-cp |  cp  |  cp  | w-cp |      |
>        +-----------------+------+------+------+------+------+
>        | m3 (Video.RTP)  | w-cp |      |      |      | w-cp |
>        +-----------------+------+------+------+------+------+
>        | m4 (Video.RTCP) | w-cp |      |      |      |  cp  |
>        +-----------------+------+------+------+------+------+
>
>
>                Figure 4: Check List State with Unfrozen Media Stream
>
>        Trickle ICE preserves all of these rules as they apply to what we
>        might call "static" check list sets.  This implies that if, for some
>        reason, a Trickle agent were to begin connectivity checks with all of
>        its pairs already present, the way that pair states change is
>        indistinguishable from that of a regular ICE agent.
>
>        Of course, the major difference with Trickle ICE is that check list
>        sets can be dynamically updated because candidates can arrive after
>        connectivity checks have started.  When this happens, an agent sets
>        the state of the newly formed pair as described below.
>
>        Case 1: If the newly formed pair is the topmost pair in this column,
>        set the state to Waiting (e.g., this would be the case if the newly
>        formed pair were placed in column 4, row 1).
>
>
>        +-----------------+------+------+------+------+------+
>        |                 |  f1  |  f2  |  f3  |  f4  |  f5  |
>        +-----------------+------+------+------+------+------+
>        | m1 (Audio.RTP)  | s-cp | w-cp | w-cp | w-cp |      |
>        +-----------------+------+------+------+------+------+
>        | m2 (Audio.RTCP) | w-cp |  cp  |  cp  | w-cp |      |
>        +-----------------+------+------+------+------+------+
>        | m3 (Video.RTP)  | w-cp |      |      |      | w-cp |
>        +-----------------+------+------+------+------+------+
>        | m4 (Video.RTCP) | w-cp |      |      |      |  cp  |
>        +-----------------+------+------+------+------+------+
>
>
>              Figure 5: Check List State with Newly Formed Pair, Case 1
>
>        Case 2: If the pair immediately above the newly formed pair in this
>        column is in the Succeeded state, set the state to Waiting (e.g.,
>        this would be the case if the pair in column 4, row 2 succeeded and
>        the newly formed pair were placed in column 4, row 3);
>
>
>        +-----------------+------+------+------+------+------+
>        |                 |  f1  |  f2  |  f3  |  f4  |  f5  |
>        +-----------------+------+------+------+------+------+
>        | m1 (Audio.RTP)  | s-cp | w-cp | w-cp |      |      |
>        +-----------------+------+------+------+------+------+
>        | m2 (Audio.RTCP) | w-cp |  cp  |  cp  | s-cp |      |
>        +-----------------+------+------+------+------+------+
>        | m3 (Video.RTP)  | w-cp |      |      | w-cp | w-cp |
>        +-----------------+------+------+------+------+------+
>        | m4 (Video.RTCP) | w-cp |      |      |      |  cp  |
>        +-----------------+------+------+------+------+------+
>
>
>              Figure 6: Check List State with Newly Formed Pair, Case 2
>
>        Case 3: If there is at least one pair in this column below the row of
>        the newly formed pair whose state is either Succeeded or Failed
>        (e.g., this would be the case if the pair in column 4, row 2
>        succeeded and the newly formed pair were placed in column 4, row 1).
>
>
>        +-----------------+------+------+------+------+------+
>        |                 |  f1  |  f2  |  f3  |  f4  |  f5  |
>        +-----------------+------+------+------+------+------+
>        | m1 (Audio.RTP)  | s-cp | w-cp | w-cp | w-cp |      |
>        +-----------------+------+------+------+------+------+
>        | m2 (Audio.RTCP) | w-cp |  cp  |  cp  | s-cp |      |
>        +-----------------+------+------+------+------+------+
>        | m3 (Video.RTP)  | w-cp |      |      | w-cp | w-cp |
>        +-----------------+------+------+------+------+------+
>        | m4 (Video.RTCP) | w-cp |      |      |      |  cp  |
>        +-----------------+------+------+------+------+------+
>
>
>              Figure 7: Check List State with Newly Formed Pair, Case 3
>
>        Case 4: In all other cases, set the state to Frozen.
>
>     ###
>
>     Peter
>
>
>
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>

-- 
https://jitsi.org

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 2 May 2017 15:56:50 -0600

> suggestions are of course welcome.

Another option, which Taylor suggested originally, is "convey initial
ICE parameters".

Personally I'm of the opinion that scrubbing every last word that
(horrors!) sounds like it might have come from SDP is a little silly,
but if we hate "description" that much then "parameters" doesn't seem
terrible.

Peter

---

From: Emil Ivov <[email-masked]>
Date: Tue, 2 May 2017 17:07:16 -0500

On 4/25/17 5:35 PM, Peter Saint-Andre wrote:
> On 4/25/17 4:16 PM, Taylor Brandstetter wrote:
>> Right. Though we could simplify it to two rules like so:
>>
>>  1. If no other pairs in the column are Waiting, set the state to Waiting.
>>  2. If another pair in the same column is Succeeded, set the state to
>>     Waiting.
>>
>> Also: it looks like version 09 will unfreeze the column if any pair *fails*:
>>
>>        Case 3: If there is at least one pair in this column above the row of
>>        the newly formed pair whose state is either Succeeded *or
>>     Failed*, set
>>        the state to Waiting (e.g., this would be the case if the pair in
>>        column 5, row 1 succeeded and two newly formed pairs were placed in
>>        column 5, rows 3 and 4).
>>
>>
>> Is this intentional?
>
> Emil wrote the original text for this section and I'm not sure why he
> included the Failed condition. It seems a bit odd to me, too...

In short: unless you do this you would otherwise never unfreeze them and 
never fully check a foundation where one of the top pairs has failed.

The fact that the state has moved to Failed is indication that enough 
time has been spent waiting on this, so unfreezing the following pairs 
for that foundation isn't going to penalize ICE processing as a whole.

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Tue, 2 May 2017 17:08:48 -0500

> but if we hate "description" that much then "parameters" doesn't seem

I don't understand what the problem is with ICE description. Would 
someone please enlighten me?

Emil

-- 
https://jitsi.org

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 2 May 2017 16:10:27 -0600

> someone please enlighten me?

It contains the word "description", and so does "session description
protocol". :-)

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 2 May 2017 16:11:38 -0600

> for that foundation isn't going to penalize ICE processing as a whole.

Sure, that makes sense. Thanks for the explanation!

Peter

---

From: Taylor Brandstetter <[email-masked]>
Date: Tue, 2 May 2017 18:39:38 -0700

>
>  I am reluctant to deal with situations where the candidate matrix is
> asymmetric

That example doesn't have asymmetric candidate matrices though; it's just 3
media streams with 2 components each, and one foundation.

> to succeed before unfreezing the foundation, I'd rather we kept things as
> they are.

Actually, what I was concerned about is that even after an entire stream
succeeds, new candidate pairs with that foundation may start as frozen.

On Tue, May 2, 2017 at 2:47 PM, Emil Ivov <[email-masked]> wrote:

> So yes, I agree this is a difference with 5245bis, but it's intentional. I
> see this in part as a simplification (I don't think it is a meaningful
> optimization even for 5245bis) but more specifically I am reluctant to deal
> with situations where the candidate matrix is asymmetric for whatever weird
> reason and one side is trying checks for M2F3 but the other isn't
> responding because M2F3 is blocked after a hole in M2F2 and it is not
> supposed to be unfrozen yet. Or something along those lines.
>
> to succeed before unfreezing the foundation, I'd rather we kept things as
> they are.
>
> Emil
>
>

---

From: Emil Ivov <[email-masked]>
Date: Wed, 03 May 2017 01:42:59 +0000

On Tue, 2 May 2017 at 20:39, Taylor Brandstetter <[email-masked]>
wrote:

> That example doesn't have asymmetric candidate matrices though; it's just
> 3 media streams with 2 components each, and one foundation.
>

I wasn't refering to that example.

> succeeds, new candidate pairs with that foundation may start as frozen.

Em. You mean in your example above?

Emil

>>>        Consider the following tabular representation of all checklists
sent from my mobile

---

From: Taylor Brandstetter <[email-masked]>
Date: Tue, 2 May 2017 19:00:03 -0700

Sorry, I thought you were responding to my example since it was quoted
above. Nevermind.

---

From: Emil Ivov <[email-masked]>
Date: Wed, 03 May 2017 02:03:36 +0000

> Sorry, I thought you were responding to my example since it was quoted

I was responding to your comment on how the new rules do not guarantee that
both components of the stream would have to succeed before a new stream for
that foundation gets unfrozen.

So I was saying that this is true but I don't think preserving this
property is essential.

I thought you were objecting to that.

Should I understand you are good then?

Emil

>>> That example doesn't have asymmetric candidate matrices though; it's
>>> just 3 media streams with 2 components each, and one foundation.
>>>
>>
>>>> So, unless someone has a great reason for why we'd need an entire
>>>> stream to succeed before unfreezing the foundation, I'd rather we kept
>>>> things as they are.
>>>
>>>
>>>> So yes, I agree this is a difference with 5245bis, but it's
>>>> intentional. I see this in part as a simplification (I don't think it is a
>>>> meaningful optimization even for 5245bis) but more specifically I am
>>>> reluctant to deal with situations where the candidate matrix is asymmetric
>>>> for whatever weird reason and one side is trying checks for M2F3 but the
>>>> other isn't responding because M2F3 is blocked after a hole in M2F2 and it
>>>> is not supposed to be unfrozen yet. Or something along those lines.
>>>>
>>>> So, unless someone has a great reason for why we'd need an entire
>>>> stream to succeed before unfreezing the foundation, I'd rather we kept
>>>> things as they are.
>>>>
>>>> Emil
>>>>
>>>>
sent from my mobile

---

From: Taylor Brandstetter <[email-masked]>
Date: Tue, 2 May 2017 22:03:19 -0700

When I said "trickle ICE only guarantees that one of them is", I meant
"only guarantees that one pair is unfrozen". I'm glad that the "both
components of a media stream" part is removed from ICEbis, but the property
I thought does make sense to preserve is "once one pair in a foundation
succeeds, every pair with that foundation is unfrozen".

On Tue, May 2, 2017 at 7:03 PM, Emil Ivov <[email-masked]> wrote:

> I was responding to your comment on how the new rules do not guarantee
> that both components of the stream would have to succeed before a new
> stream for that foundation gets unfrozen.
>
>>>> Actually, what I was concerned about is that even after an entire
>>>> stream succeeds, new candidate pairs with that foundation may start as
>>>> frozen.
>>>>
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 May 2017 06:12:10 +0000

Hi,

I am a little confused, because I don’t know if you talk about text currently in 5245bis, or text that you would like to see in 5245bis :)

CURRENTLY in 5245bis, once a pair succeeds, all other pairs for the same foundation are unfrozen. There is no rule saying that, for a given stream, all components have to succeed before the other streams are unfrozen.

Is that how you want it? Do you want to change that? Or, don’t you agree that is what 5245bis currently says in the first place?

Regards,

Christer

From: Ice <[email-masked]<mailto:[email-masked]>> on behalf of Taylor Brandstetter <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 3 May 2017 at 08:03
To: Emil Ivov <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] holes in the matrix (Was: Taylor's review of draft-ietf-ice-trickle-08.txt)

When I said "trickle ICE only guarantees that one of them is", I meant "only guarantees that one pair is unfrozen". I'm glad that the "both components of a media stream" part is removed from ICEbis, but the property I thought does make sense to preserve is "once one pair in a foundation succeeds, every pair with that foundation is unfrozen".

On Tue, May 2, 2017 at 7:03 PM, Emil Ivov <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, 2 May 2017 at 21:00, Taylor Brandstetter <[email-masked]<mailto:[email-masked]>> wrote:
Sorry, I thought you were responding to my example since it was quoted above. Nevermind.

I was responding to your comment on how the new rules do not guarantee that both components of the stream would have to succeed before a new stream for that foundation gets unfrozen.

So I was saying that this is true but I don't think preserving this property is essential.

Emil

On Tue, May 2, 2017 at 6:42 PM, Emil Ivov <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, 2 May 2017 at 20:39, Taylor Brandstetter <[email-masked]<mailto:[email-masked]>> wrote:
 I am reluctant to deal with situations where the candidate matrix is asymmetric

That example doesn't have asymmetric candidate matrices though; it's just 3 media streams with 2 components each, and one foundation.

So, unless someone has a great reason for why we'd need an entire stream to succeed before unfreezing the foundation, I'd rather we kept things as they are.

Actually, what I was concerned about is that even after an entire stream succeeds, new candidate pairs with that foundation may start as frozen.

Emil

On Tue, May 2, 2017 at 2:47 PM, Emil Ivov <[email-masked]<mailto:[email-masked]>> wrote:
Hey,

So yes, I agree this is a difference with 5245bis, but it's intentional. I see this in part as a simplification (I don't think it is a meaningful optimization even for 5245bis) but more specifically I am reluctant to deal with situations where the candidate matrix is asymmetric for whatever weird reason and one side is trying checks for M2F3 but the other isn't responding because M2F3 is blocked after a hole in M2F2 and it is not supposed to be unfrozen yet. Or something along those lines.

So, unless someone has a great reason for why we'd need an entire stream to succeed before unfreezing the foundation, I'd rather we kept things as they are.

Emil

On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    been
    "Frozen"

    ###

    ###

    Peter

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

--
https://jitsi.org

--
sent from my mobile

--
sent from my mobile

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 3 May 2017 09:00:29 -0700

> Is that how you want it?

Yes. 5245 had this rule, 5245bis does not, and I'm happy with that.

I'm glad that the "both components of a media stream" part is removed from
> ICEbis

On Tue, May 2, 2017 at 11:12 PM, Christer Holmberg <
[email-masked]> wrote:

>
> Hi,
>
> I am a little confused, because I don’t know if you talk about text
> currently in 5245bis, or text that you would like to see in 5245bis :)
>
> CURRENTLY in 5245bis, once a pair succeeds, all other pairs for the same
> foundation are unfrozen. There is no rule saying that, for a given stream,
> all components have to succeed before the other streams are unfrozen.
>
> Is that how you want it? Do you want to change that? Or, don’t you agree
> that is what 5245bis currently says in the first place?
>
> Regards,
>
> Christer
>
> From: Ice <[email-masked]> on behalf of Taylor Brandstetter <
> [email-masked]>
> To: Emil Ivov <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>

---

From: Emil Ivov <[email-masked]>
Date: Wed, 3 May 2017 11:30:01 -0500

On 5/3/17 12:03 AM, Taylor Brandstetter wrote:
> components of a media stream" part is removed from ICEbis,

I'll skip the 5245bis part of the discussion until we are done with the 
trickle one.

> but the
> property I thought does make sense to preserve is "once one pair in a
> foundation succeeds, every pair with that foundation is unfrozen".

I am not sure I follow. Why is this not preserved? State changes 
themselves happen as they do in 5245bis. Trickle only defines what 
happens with newly added candidates and for the case you mention we have 
this:

    Case 3: If there is at least one pair in this column above the row of
    the newly formed pair whose state is either Succeeded or Failed, set
    the state to Waiting (e.g., this would be the case if the pair in
    column 5, row 1 succeeded and two newly formed pairs were placed in
    column 5, rows 3 and 4).

Which translates to exactly what you have in the quotes above.

What's bothering you about it?

Emil

>     On Tue, 2 May 2017 at 21:00, Taylor Brandstetter
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I was responding to your comment on how the new rules do not
>     guarantee that both components of the stream would have to succeed
>     before a new stream for that foundation gets unfrozen.
>
>             On Tue, 2 May 2017 at 20:39, Taylor Brandstetter
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 That example doesn't have asymmetric candidate matrices
>                 though; it's just 3 media streams with 2 components
>                 each, and one foundation.
>
>
>                     So, unless someone has a great reason for why we'd
>                     need an entire stream to succeed before unfreezing
>                     the foundation, I'd rather we kept things as they are.
>
>
>                 Actually, what I was concerned about is that even after
>                 an entire stream succeeds, new candidate pairs with that
>                 foundation may start as frozen.
>
>
>                 On Tue, May 2, 2017 at 2:47 PM, Emil Ivov
>                 <[email-masked] <mailto:[email-masked]>> wrote:
>
>                     Hey,
>
>                     So yes, I agree this is a difference with 5245bis,
>                     but it's intentional. I see this in part as a
>                     simplification (I don't think it is a meaningful
>                     optimization even for 5245bis) but more specifically
>                     I am reluctant to deal with situations where the
>                     candidate matrix is asymmetric for whatever weird
>                     reason and one side is trying checks for M2F3 but
>                     the other isn't responding because M2F3 is blocked
>                     after a hole in M2F2 and it is not supposed to be
>                     unfrozen yet. Or something along those lines.
>
>                     So, unless someone has a great reason for why we'd
>                     need an entire stream to succeed before unfreezing
>                     the foundation, I'd rather we kept things as they are.
>
>                     Emil
>
>
>                         <mailto:[email-masked]>
>                         [email-masked] <mailto:[email-masked]>
>                         <https://www.ietf.org/mailman/listinfo/ice>
>
>
>                     --
>                     https://jitsi.org
>
>
>             --
>             sent from my mobile
>
>
>     --
>     sent from my mobile
>
>

-- 
https://jitsi.org

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 3 May 2017 09:45:36 -0700

> themselves happen as they do in 5245bis. Trickle only defines what happens
> with newly added candidates and for the case you mention we have this:
>

I think we're on the same page, just mis-communicating. My email quoted at
the start of this thread was talking about version 08; the problem is fixed
in version 09. The only thing that concerns me about version 09 is the "or
Failed" part (see:
https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA).

On Wed, May 3, 2017 at 9:30 AM, Emil Ivov <[email-masked]> wrote:

> themselves happen as they do in 5245bis. Trickle only defines what happens
> with newly added candidates and for the case you mention we have this:
>
>>                     candidate matrix is asymmetric
>>
>>
>>                         <mailto:[email-masked]
>>
>>                         <mailto:[email-masked]>>> wrote:
>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 3 May 2017 20:06:51 -0600

On 5/3/17 10:45 AM, Taylor Brandstetter wrote:
>     happens with newly added candidates and for the case you mention we
>     have this:
> 
> I think we're on the same page, just mis-communicating. My email quoted
> at the start of this thread was talking about version 08; the problem is
> fixed in version 09. The only thing that concerns me about version 09 is
> the "or Failed" part
> (see: https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA).

Emil posted in this thread about that yesterday. His explanation was:

   The fact that the state has moved to Failed is indication that
   enough time has been spent waiting on this, so unfreezing the
   following pairs for that foundation isn't going to penalize ICE
   processing as a whole.

Does that ring true to you, and if so do you think we need to add
explanatory text to that effect?

Peter

---

From: Taylor Brandstetter <[email-masked]>
Date: Thu, 4 May 2017 07:00:40 -0700

That's not always necessarily true, since the state may go to Failed due to
reasons other than a timeout. It would be unfortunate if this rule resulted
in more time slots given to a foundation that doesn't work, and less to a
foundation that does. It also seems odd that there's no equivalent
condition in ICEbis; every other condition has a parallel of some sort.

---

From: Emil Ivov <[email-masked]>
Date: Thu, 4 May 2017 09:58:29 -0500

On 5/3/17 11:45 AM, Taylor Brandstetter wrote:
> fixed in version 09.

That rule was actually there since 08:

    Waiting:   if the pair immediately above the newly formed pair in
    this column is in the Succeeded state;

which is why was confused. I do like the current wording better though.

> The only thing that concerns me about version 09 is
> the "or Failed" part

Will respond on the other thread.

Emil

>
>
> On Wed, May 3, 2017 at 9:30 AM, Emil Ivov <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     I'll skip the 5245bis part of the discussion until we are done with
>     the trickle one.
>
>         but the
>         On Tue, May 2, 2017 at 7:03 PM, Emil Ivov <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>
>             <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>                 Sorry, I thought you were responding to my example since
>         it was
>                 quoted above. Nevermind.
>
>
>                 On Tue, May 2, 2017 at 6:42 PM, Emil Ivov
>         <[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>
>                     <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>                         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>                             Hey,
>
>                                     Taylor, would you mind spelling this
>         out a
>                                 bit more fully and point to
>                                     discrepancies between the text of
>         5245bis
>                                 and the text of the Trickle
>                                     spec? I'm sure I'm missing
>         something, but I
>                                 don't yet see the truth of
>                                 simple). I'll represent the states like
>         this for
>                                 brevity: "SWFFFF",
>                                 where "S" is "succeeded", "W" is
>         "waiting", and
>                                 "F" is "frozen". And
>                                 they're ordered in the same way as the
>         rows in
>                                 your table above.
>
>                                  1. Only the RTP candidate pair for the
>         first
>                                 media stream is unfrozen
>                                     initially.
>                                     State: WFFFFF
>                                  2. Check succeeds for RTP candidate
>         pair. RTCP
>                                 pair unfrozen.
>                                     State: SWFFFF
>                                  1. Candidates for the first media
>         stream are
>                                 trickled in. Starts out
>                                     just like normal ICE.
>                                     State: WF
>                                  2. Checks for both pairs succeed. Still
>         waiting
>                                 for candidates for
>                                     other media streams.
>                                     State: SS
>                                     The topmost pair is set to waiting,
>         but not
>                                 the others.
>                                     State: SSWFFF
>
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>>>> wrote:
>
>                                     >   * In section 8.1.1: In general I
>         like
>                                 the improvements that have
>                                     been
>                                     >     made. However:
>                                     >       o The rules for how a new
>         pair gets
>                                 either a "Waiting" or
>                                     "Frozen"
>                                     >         streams with matching
>         foundations
>                                 are unfrozen. With the current
>                                     >         rules in section 8.1.1,
>         only the
>                                 topmost remaining pair in each
>                                     >         acceptable? If it is, we
>         should at
>                                 least acknowledge it, and not
>                                     Taylor, would you mind spelling this
>         out a
>                                 bit more fully and point to
>                                     discrepancies between the text of
>         5245bis
>                                 and the text of the Trickle
>                                     spec? I'm sure I'm missing
>         something, but I
>                                 don't yet see the truth of
>                                     In particular, your statement
>         doesn't seem
>                                 to match the rules defined in
>                                     the Trickle spec. I've tried to
>         spell them
>                                 out in greater detail (with
>                                        |                 |  f1  |  f2
>         |  f3  |
>                                 f4  |  f5  |
>                                        | m1 (Audio.RTP)  |  cp  |  cp
>         |  cp  |
>                                     |      |
>
>
>                                        | m2 (Audio.RTCP) |  cp  |  cp
>         |  cp  |
>                                 cp  |      |
>
>
>                                        | m3 (Video.RTP)  |  cp  |
>         |      |
>                                     |  cp  |
>                                        | m4 (Video.RTCP) |  cp  |
>         |      |
>                                     |  cp  |
>                                        Each column represents one
>         foundation.
>                                 Each cell represents one
>                                        candidate pair.
>
>                                        When an agent commences ICE
>         processing,
>                                 in accordance with
>                                        Section 5.1.3.6 of [rfc5245bis]
>         it will
>                                 unfreeze (i.e., place in the
>                                        Waiting state) the topmost
>         candidate pair
>                                 in every column (i.e., the
>                                        pair with the lowest component
>         ID).  This
>                                 state is shown in the
>                                        following table, with candidate
>         pairs in
>                                 the Waiting state marked by
>                                        "w-cp".
>
>
>
>
>                                        |                 |  f1  |  f2
>         |  f3  |
>                                 f4  |  f5  |
>                                        | m1 (Audio.RTP)  | w-cp | w-cp |
>         w-cp |
>                                     |      |
>
>
>                                        | m2 (Audio.RTCP) |  cp  |  cp
>         |  cp  |
>                                 w-cp |      |
>
>
>                                        | m3 (Video.RTP)  |  cp  |
>         |      |
>                                     | w-cp |
>                                        | m4 (Video.RTCP) |  cp  |
>         |      |
>                                     |  cp  |
>                                                         Figure 2:
>         Initial Check
>                                 List State
>                                        Then, as the checks proceed (see
>         Section
>                                 6.1.2.4.2.3 of
>                                        [rfc5245bis]), for each pair that
>         enters
>                                 the Succeeded state (denoted
>                                        here by "s-cp"), the agent will
>         unfreeze
>                                 all pairs for the same media
>                                        stream and foundation (e.g., if
>         the pair
>                                 in column 1, row 1 succeeds
>                                        then the agent will unfreeze the
>         pair in
>                                 column 1, row 2).
>
>
>
>
>                                        |                 |  f1  |  f2
>         |  f3  |
>                                 f4  |  f5  |
>                                        | m1 (Audio.RTP)  | s-cp | w-cp |
>         w-cp |
>                                     |      |
>
>
>                                        | m2 (Audio.RTCP) | w-cp |  cp
>         |  cp  |
>                                 w-cp |      |
>
>
>                                        | m3 (Video.RTP)  |  cp  |
>         |      |
>                                     | w-cp |
>                                        | m4 (Video.RTCP) |  cp  |
>         |      |
>                                     |  cp  |
>                                        ICE also specifies that, if all
>         the pairs
>                                 in a media stream for one
>                                        foundation are unfrozen (e.g.,
>         column 1,
>                                 rows 1 and 2 representing
>                                        both components for the audio
>         stream),
>                                 then all of the candidate
>                                        pairs in the entire column are
>         unfrozen
>                                 (e.g., column 1, rows 3 and
>                                        4).
>
>
>
>
>
>                                        |                 |  f1  |  f2
>         |  f3  |
>                                 f4  |  f5  |
>                                        | m1 (Audio.RTP)  | s-cp | w-cp |
>         w-cp |
>                                     |      |
>
>
>                                        | m2 (Audio.RTCP) | w-cp |  cp
>         |  cp  |
>                                 w-cp |      |
>
>
>                                        | m3 (Video.RTP)  | w-cp |
>         |      |
>                                     | w-cp |
>
>
>                                        | m4 (Video.RTCP) | w-cp |
>         |      |
>                                     |  cp  |
>
>
>                                                Figure 4: Check List
>         State with
>                                 Unfrozen Media Stream
>                                        Trickle ICE preserves all of
>         these rules
>                                 as they apply to what we
>                                        its pairs already present, the
>         way that
>                                 pair states change is
>                                        indistinguishable from that of a
>         regular
>                                 ICE agent.
>
>                                        sets can be dynamically updated
>         because
>                                 candidates can arrive after
>                                        connectivity checks have
>         started.  When
>                                 this happens, an agent sets
>                                        Case 1: If the newly formed pair
>         is the
>                                 topmost pair in this column,
>                                        |                 |  f1  |  f2
>         |  f3  |
>                                 f4  |  f5  |
>                                        | m1 (Audio.RTP)  | s-cp | w-cp |
>         w-cp |
>                                 w-cp |      |
>
>
>                                        | m2 (Audio.RTCP) | w-cp |  cp
>         |  cp  |
>                                 w-cp |      |
>
>
>                                        | m3 (Video.RTP)  | w-cp |
>         |      |
>                                     | w-cp |
>
>
>                                        | m4 (Video.RTCP) | w-cp |
>         |      |
>                                     |  cp  |
>
>
>                                        Case 2: If the pair immediately
>         above the
>                                 newly formed pair in this
>                                        column is in the Succeeded state,
>         set the
>                                 state to Waiting (e.g.,
>                                        |                 |  f1  |  f2
>         |  f3  |
>                                 f4  |  f5  |
>                                        | m1 (Audio.RTP)  | s-cp | w-cp |
>         w-cp |
>                                     |      |
>
>
>                                        | m2 (Audio.RTCP) | w-cp |  cp
>         |  cp  |
>                                 s-cp |      |
>
>
>                                        | m3 (Video.RTP)  | w-cp |
>         |      |
>                                 w-cp | w-cp |
>
>
>                                        | m4 (Video.RTCP) | w-cp |
>         |      |
>                                     |  cp  |
>
>
>                                        Case 3: If there is at least one
>         pair in
>                                 this column below the row of
>                                        (e.g., this would be the case if
>         the pair
>                                 in column 4, row 2
>                                        succeeded and the newly formed
>         pair were
>                                 placed in column 4, row 1).
>
>
>
>
>                                        |                 |  f1  |  f2
>         |  f3  |
>                                 f4  |  f5  |
>                                        | m1 (Audio.RTP)  | s-cp | w-cp |
>         w-cp |
>                                 w-cp |      |
>
>
>                                        | m2 (Audio.RTCP) | w-cp |  cp
>         |  cp  |
>                                 s-cp |      |
>
>
>                                        | m3 (Video.RTP)  | w-cp |
>         |      |
>                                 w-cp | w-cp |
>
>
>                                        | m4 (Video.RTCP) | w-cp |
>         |      |
>                                     |  cp  |
>
>
>                                        Case 4: In all other cases, set
>         the state
>                                 to Frozen.
>
>                                     ###
>
>                                     Peter
>
>
>
>
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>
>         <https://www.ietf.org/mailman/listinfo/ice
>         <https://www.ietf.org/mailman/listinfo/ice>>
>
>
>                             --
>                             https://jitsi.org
>
>
>                     --
>                     sent from my mobile
>
>
>             --
>             sent from my mobile
>
>
>
>     --
>     https://jitsi.org
>
>

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Thu, 4 May 2017 10:40:44 -0500

On 5/4/17 9:00 AM, Taylor Brandstetter wrote:
> That's not always necessarily true, since the state may go to Failed due
> to reasons other than a timeout.

Yes, indeed. That could happen and the reason would be something like a 
transport error or an ICMP port unreachable. We could optimize for this 
by adding a second go at the end where all the failed foundations are 
given another attempt.

This wouldn't be trivial to write up and I am reluctant to do it because:

1. it adds complexity to both the specification and implementations for 
low value: you only save one time slot per pair. You don't even have to 
worry about retransmissions.
2. the timeout case is arguably significantly more common

One alternative that I would find acceptable is to simply scratch the 
entire foundation if the first pair there fails. I think that would work 
fine and it would be simple to write up but I know people on this list 
feel strongly about trying every pair and I get that point of view too.

> It would be unfortunate if this rule
> resulted in more time slots given to a foundation that doesn't work, and
> less to a foundation that does.

I don't believe this statement is accurate. You may end up giving slots 
in the wrong order but I don't see how you could give more to the 
non-working and less to the working.

Emil

> It also seems odd that there's no
> equivalent condition in ICEbis; every other condition has a parallel of
> some sort.

>
> On Wed, May 3, 2017 at 7:06 PM, Peter Saint-Andre <[email-masked]
>     > (see: https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA <https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA>).
>

-- 
https://jitsi.org

---

From: Taylor Brandstetter <[email-masked]>
Date: Thu, 4 May 2017 09:17:48 -0700

>
> We could optimize for this by adding a second go at the end where all the
> failed foundations are given another attempt.

This already happens with ICEbis, though:

   Whenever Ta fires, the agent will perform a check for a candidate

   pair within the selected CHECK LIST as follows: ...

   o  If there is no candidate pair in the Waiting state, and if there

      are one or more pairs in the Frozen state, for each pair in the
>       Frozen state the the agent checks the foundation associated with
>       the pair.  For a given foundation, if there is no pair (in any
>       CHECK LIST in the CHECK LIST SET) in the Waiting or In-Progress
>       state, the agent performs a connectivity check on the pair and
>       puts the pair state to In-Prograss.

That's why I don't see the need for trickle ICE to do anything special with
Failed candidate pairs. It's already guaranteed that failed foundations
will be tried *eventually*, so what's gained by unfreezing these pairs
earlier?

On Thu, May 4, 2017 at 8:40 AM, Emil Ivov <[email-masked]> wrote:

> transport error or an ICMP port unreachable. We could optimize for this by
> adding a second go at the end where all the failed foundations are given
> another attempt.
>
> fine and it would be simple to write up but I know people on this list feel
> strongly about trying every pair and I get that point of view too.
>
> I don't believe this statement is accurate. You may end up giving slots in
> the wrong order but I don't see how you could give more to the non-working
> and less to the working.
>
> Emil
>
>>     > (see: https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE
>> 3idlmobyA <https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHX
>> E3idlmobyA>).
>>

---

From: Emil Ivov <[email-masked]>
Date: Thu, 4 May 2017 11:28:02 -0500

On Thu, May 4, 2017 at 11:17 AM, Taylor Brandstetter
<[email-masked]> wrote:
> Failed candidate pairs. It's already guaranteed that failed foundations will
> be tried eventually, so what's gained by unfreezing these pairs earlier?

I was actually just rereading the same part.

I think you've won me over. I'll remove this in a minute.

Emil
>>>     > (see:
>>> https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA
>>> <https://mailarchive.ietf.org/arch/msg/ice/6oDf6yNanCgjj1yHXE3idlmobyA>).
>>>

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Thu, 4 May 2017 11:30:48 -0500

> I think you've won me over. I'll remove this in a minute.

Done.

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 May 2017 18:40:12 +0000

Hi,

Related to the text below, note that it may actually trigger multiple checks simultaneously (normally only a single check is triggered whenever Ta fires). Are we ok with that? If not, I guess we would have to select the pair with the highest priority.

Regards,

Christer

From: Ice [mailto:[email-masked]] On Behalf Of Taylor Brandstetter
Sent: 04 May 2017 18:18
To: Emil Ivov <[email-masked]>
Cc: Peter Saint-Andre <[email-masked]>; [email-masked]
Subject: Re: [Ice] holes in the matrix (Was: Taylor's review of draft-ietf-ice-trickle-08.txt)

We could optimize for this by adding a second go at the end where all the failed foundations are given another attempt.

That's why I don't see the need for trickle ICE to do anything special with Failed candidate pairs. It's already guaranteed that failed foundations will be tried eventually, so what's gained by unfreezing these pairs earlier?

On Thu, May 4, 2017 at 8:40 AM, Emil Ivov <[email-masked]<mailto:[email-masked]>> wrote:

Yes, indeed. That could happen and the reason would be something like a transport error or an ICMP port unreachable. We could optimize for this by adding a second go at the end where all the failed foundations are given another attempt.

1. it adds complexity to both the specification and implementations for low value: you only save one time slot per pair. You don't even have to worry about retransmissions.
2. the timeout case is arguably significantly more common

One alternative that I would find acceptable is to simply scratch the entire foundation if the first pair there fails. I think that would work fine and it would be simple to write up but I know people on this list feel strongly about trying every pair and I get that point of view too.
It would be unfortunate if this rule
resulted in more time slots given to a foundation that doesn't work, and
less to a foundation that does.

I don't believe this statement is accurate. You may end up giving slots in the wrong order but I don't see how you could give more to the non-working and less to the working.

Emil

On Wed, May 3, 2017 at 7:06 PM, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Peter

--
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Thu, 4 May 2017 13:59:55 -0500

In all fairness I find that text rather hard to follow. It's
definitely clearer in 5245. I am curious what the reason for changing
it was?

And to answer your question: yes, performing multiple transactions at
the same time directly breaks pacing.

Emil

On Thu, May 4, 2017 at 1:40 PM, Christer Holmberg
<[email-masked]> wrote:
> Hi,
>
>
>
> Related to the text below, note that it may actually trigger multiple checks
> simultaneously (normally only a single check is triggered whenever Ta
> fires). Are we ok with that? If not, I guess we would have to select the
> pair with the highest priority.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> 1. it adds complexity to both the specification and implementations for low
> value: you only save one time slot per pair. You don't even have to worry
> about retransmissions.
> One alternative that I would find acceptable is to simply scratch the entire
> foundation if the first pair there fails. I think that would work fine and
> it would be simple to write up but I know people on this list feel strongly
> about trying every pair and I get that point of view too.
>

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 May 2017 19:19:39 +0000

Hi,

>In all fairness I find that text rather hard to follow. 

Well, whenever I suggested new text I presented it to the list. Nobody said anything...

>It's definitely clearer in 5245. I am curious what the reason for changing it was?

It's all more or less a side effect of the addition of "Emil's list" :) 

However, I personally think that the procedures are easier to understand now.

>And to answer your question: yes, performing multiple transactions at the same time >directly breaks pacing.

So, perhaps we need to fix that. 

Also, the case should only occur (at least without trickle) when a previous check for the same foundation(s) have failed.

Regards,

Christer

On Thu, May 4, 2017 at 1:40 PM, Christer Holmberg <[email-masked]> wrote:
> Hi,
>
>
>
> Related to the text below, note that it may actually trigger multiple 
> checks simultaneously (normally only a single check is triggered 
> whenever Ta fires). Are we ok with that? If not, I guess we would have 
> to select the pair with the highest priority.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> We could optimize for this by adding a second go at the end where all 
> the failed foundations are given another attempt.
>
>
>
> That's why I don't see the need for trickle ICE to do anything special 
> with Failed candidate pairs. It's already guaranteed that failed 
> foundations will be tried eventually, so what's gained by unfreezing these pairs earlier?
>
>
>
>
>
>
>
> That's not always necessarily true, since the state may go to Failed 
> due to reasons other than a timeout.
>
>
> Yes, indeed. That could happen and the reason would be something like 
> a transport error or an ICMP port unreachable. We could optimize for 
> this by adding a second go at the end where all the failed foundations 
> are given another attempt.
>
> value: you only save one time slot per pair. You don't even have to 
> entire foundation if the first pair there fails. I think that would 
> work fine and it would be simple to write up but I know people on this 
> list feel strongly about trying every pair and I get that point of view too.
>
> resulted in more time slots given to a foundation that doesn't work, 
> and less to a foundation that does.
>
>
> I don't believe this statement is accurate. You may end up giving 
> slots in the wrong order but I don't see how you could give more to 
> the non-working and less to the working.
>
> Emil
>
> equivalent condition in ICEbis; every other condition has a parallel 
> of some sort.
>
>
>
>

--
https://jitsi.org

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 4 May 2017 19:57:28 -0600

>> I think you've won me over. I'll remove this in a minute.

Co-author +1 :-)

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 May 2017 11:04:22 +0000

Hi,

I¹ve created a pull request, which ensures that multiple connectivity
checks won¹t be triggered at the same time.

https://github.com/ice-wg/rfc5245bis/pull/33

(Note that the only case when, for a given foundation, there will be no
pair in the Waiting/In-Progress state, is when a check for that foundation
has failed.)

Regards,

Christer

On 04/05/17 21:59, "Emil Ivov" <[email-masked]> wrote:

>>checks
>>the
>>with
>>will
>>by
>>low
>>entire
>>in
>>     >     happens with newly added candidates and for the case you
>>mention
>> we
>>     >     have this:
>>     >
>>     >        Case 3: If there is at least one pair in this column above
>>the
>> row of
>>     >        the state to Waiting (e.g., this would be the case if the
>>pair
>> in
>>     > at the start of this thread was talking about version 08; the
>>problem
>> is
>>     > fixed in version 09. The only thing that concerns me about
>>version 09
>> is
>>     > the "or Failed" part
>>     > (see:

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 May 2017 19:59:12 -0600

Thanks, Christer.

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 17 May 2017 22:30:02 -0700

I took a look at version 10, which still says:

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

I still don't see how this is true. If it is, I can't find where this
independently monitored state is used. So I think this sentence and
the rest of the paragraph should be removed.

Also, while looking for where it's referenced, I noticed that Section
10 still mentions a check list in an "Active" state, when it should
say "Running".

On Mon, Apr 10, 2017 at 1:05 PM, Peter Saint-Andre <[email-masked]>
wrote:

> On 4/10/17 1:56 PM, Taylor Brandstetter wrote:
> >     it's true that the agent needs to monitor the
> >     "state" of the check list (note: no such check list state is actually
> >     defined in 5245bis) independent of the state of the candidate pairs
> in
> >     the list
> >
> >
> > I don't see how this is true any more. If this additional
> > "frozen/active" flag is necessary, where is it used? Previously, I
> > assumed it was used to set the state of the first candidate pair in a
> > checklist to either "Waiting" or "Frozen". But the state of the first
> > pair will now /always/ be set to "Waiting" (due to the "topmost in
> > column" rule). Maybe section 8.1.1 was intended to reference this
> > "frozen/active" check list state? But it doesn't currently.
>
> Agreed. We'll need to clean up the text across these sections. I'll try
> to formulate proposed text this evening.
>
> > Also, the latest draft of RFC5245bis /does/ still define a check list
> > state. See section 5.1.3.1
> > <https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-08#
> section-5.1.3.1>,
> > "Check List State".
>
> Right, but not check list states of Active or Frozen (only Running,
> Completed, and Failed).
>
> Peter
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 May 2017 09:05:26 +0000

Hi,

Based on a comment from Taylor, I have added a flow chart that illustrates
the procedures.

Regards,

Christer