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

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 9 Apr 2017 16:52:47 -0600

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

>   * In section 5.2: "With regard to pruning of duplicate candidate
>     pairs, a Trickle ICE agent SHOULD follow a policy of pruning the
>     lower priority candidate unless it is peer reflexive." This makes it
>     sound like peer reflexive candidates are /never/ pruned, but it's
>     the opposite; they're /always/ pruned, as described in Section 8.1.
>     Also, in ICEbis, candidates themselves aren't pruned, only candidate
>     pairs are.

Peter Thatcher suggested changing this to "a policy of keeping the
higher priority candidate unless it is peer reflexive". Does that meet
your needs?

>   * In section 7.2: "Therefore a Trickle ICE agent MUST 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), and MUST consider a check list to be active whenever it
>     adds the first candidate pair with a state of Waiting to the check
>     list (see Section 8.1.1)." The first MUST seems redundant with the
>     second. 

I don't see a harmful redundancy here.

> In earlier drafts, the purpose of monitoring the
>     "active/frozen" state independently was so that if a check list is
>     empty and frozen, the first pair added starts as "Frozen", while if
>     it's empty and active, the first pair added starts as "Waiting." If
>     the first pair /always/ starts as "Waiting," then tracking the
>     active/frozen state of a check list independently is no longer
>     necessary. 

The foregoing text does not say that the first pair always starts as
Waiting. Do you think it should?

> Though I don't see anything in Section 8.1.1 that relates
>     specifically to this, so I'm not sure what "see Section 8.1.1" is
>     referring to.

Perhaps we'll remove that pointer.

>   * 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."
>       o The rule that a pair changes to "Waiting" if a pair in a lower
>         row is "Succeeded" means that if a pair in the lowermost row is
>         unfrozen first (which is possible, if the signaling mechanism
>         doesn't preserve ordering of candidates), all of the other pairs
>         with its foundation would be unfrozen as soon as it's unfrozen.
>         This seems odd.

I'll talk with Emil about this.

>   * As mentioned in a different email thread, Section 16 doesn't make
>     sense any more if the signaling protocol isn't required to preserve
>     candidate ordering.

See other thread.

> I also found a couple of really trivial things, which I made a PR
> for: https://github.com/ice-wg/trickle/pull/10

Merged.

Peter

---

From: Taylor Brandstetter <[email-masked]>
Date: Sun, 9 Apr 2017 22:09:53 -0700

> higher priority candidate unless it is peer reflexive". Does that meet

That sounds good.

> Waiting. Do you think it should?

The foregoing text doesn't say the first pair starts as Waiting, but
section 8.1.1 does. My overall point is that monitoring the active/frozen
state independently isn't necessary with the new algorithm in 8.1.1, so
this whole paragraph seems like it's outdated and can be removed.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Apr 2017 13:44:23 -0600

On 4/9/17 11:09 PM, Taylor Brandstetter wrote:

> section 8.1.1 does. My overall point is that monitoring the
> active/frozen state independently isn't necessary with the new algorithm
> in 8.1.1, so this whole paragraph seems like it's outdated and can be
> removed.

Good catch. So although 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, to your point the second clause ("MUST consider a check list
to be active whenever it adds the first candidate pair with a state of
Waiting to the check list") is unnecessary here because 8.1.1 now says
how to handle things (i.e., when inserting a new candidate pair into an
empty check list, set it to a state of Waiting).

Does that sound right?

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Apr 2017 13:53:53 -0600

> empty check list, set it to a state of Waiting).

Hmm, not exactly. I'll need to think about this when I'm not at the
office. :-)

---

From: Taylor Brandstetter <[email-masked]>
Date: Mon, 10 Apr 2017 12:56:51 -0700

>
> it's true that the agent needs to monitor the
> 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.

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Apr 2017 14:05:51 -0600

On 4/10/17 1:56 PM, Taylor Brandstetter wrote:
> 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

Right, but not check list states of Active or Frozen (only Running,
Completed, and Failed).

Peter

---

From: Taylor Brandstetter <[email-masked]>
Date: Mon, 10 Apr 2017 15:07:41 -0700

It still mentions "active" and "frozen" at the end:

"A check list with at least one pair that is Waiting is called an active
check list, and a check list with all pairs Frozen is called a frozen check
list."

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Apr 2017 16:23:38 -0600

On 4/10/17 4:07 PM, Taylor Brandstetter wrote:
> check list, and a check list with all pairs Frozen is called a frozen
> check list."

Yes. I was being pedantic: they're not actually *states*.

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Apr 2017 06:40:55 +0000

Hi,

A comment regarding states etc in 5245bis.

5245bis contains lots of different states, and non-state properties, and
as part of the ³clean up² process I have tried to simplify (and perhaps
even remove) much of that.

As I have had to spend my time on a bunch of MMUSIC drafts, the work on
5245bis has been on hold for a while, but my intention is to continue the
work very shortly.

Regards,

Christer

On 10/04/17 23:05, "Ice on behalf of Peter Saint-Andre"
<[email-masked] on behalf of [email-masked]> wrote:

>><https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-08#section-5.1.3.1
>>>,
>> "Check List State".
>
>_______________________________________________
>Ice mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ice

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 14 Apr 2017 20:01:26 -0600

>>   * In section 8.1.1: In general I like the improvements that have been

I've looked at this again and have a few questions.

>>         state don't completely match standard ICE; 

Well, regular ICE doesn't have a concept of "new pair" in the sense that
Trickle ICE does, but I see what you mean.

It seems to me that the best way to explain things here is by showing
snapshots of the tabular representation over time as new pairs are
added, somewhat as is done in Section 5.1.3.6 of 5245bis. This will
increase the length of Section 8.1.1 significantly.

>> at least the part

That sentence was meant to reinforce that the rules for regular ICE
processing of "static" check lists still apply to Trickle ICE agents.
The question is how to handle new pairs. However, as you note, right now
the new-pair rules at the end of Section 8.1.1 aren't entirely
consistent with 5245bis.

This weekend I will look into the discrepancies in more detail, in part
by sketching out the snapshots as mentioned above.

>>         doesn't preserve ordering of candidates),

We've agreed to add that rule back in (unless there are objections
during WGLC).

>> all of the other pairs

This might not be a worry anymore given the just-mentioned text
reinstatement.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 17 Apr 2017 21:16:06 -0600

[areas of seeming agreement elided]

>         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

---

From: Taylor Brandstetter <[email-masked]>
Date: Tue, 18 Apr 2017 18:44:15 -0700

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 23 Apr 2017 15:57:45 -0600

On 4/18/17 7:44 PM, Taylor Brandstetter wrote:
> 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.
> 

Section 6.2.5.3.3 of 5245bis states:

   The success of the connectivity check might also cause the state of
   other candidate pairs to change.  The ICE agent MUST set the states
   for all other Frozen candidate pairs (in each CHECK LIST in the CHECK
   LIST SET) with the same foundation to Waiting.

Does that mean we'd go directly from WFFFFF to SWWWWW?

>  3. Check succeeds for RTCP pair. /All/ the other pairs with the same
>  2. Checks for both pairs succeed. Still waiting for candidates for
>     other media streams.
>     State: SS

Thanks for the example.

My interpretation of Case 1 is that only the topmost pair for that
foundation is set to waiting, however you seem to interpret it to mean
the topmost pair for that media stream.

I agree that the rules in draft-ietf-ice-trickle-08 aren't quite right.
If we accept my interpretation of the "topmost pair" rule, then I think
the fix we need to make is to Case 3 (change "below" to "above").

In the interest of time, I'm going to submit -09 right now so that we
have a document and diff to review, not just these long email messages.

Peter

> 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.
> 
> On Mon, Apr 17, 2017 at 8:16 PM, Peter Saint-Andre <[email-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: Taylor Brandstetter <[email-masked]>
Date: Mon, 24 Apr 2017 11:01:51 -0700

> Does that mean we'd go directly from WFFFFF to SWWWWW?

Yes; when I was typing up the example I hadn't noticed that the "each
component of the media stream" part had been removed from 5245bis.

> the topmost pair for that media stream.

No, I also interpret it as "topmost for foundation".

 I think the fix we need to make is to Case 3 (change "below" to "above").

I think you could merge cases 2 and 3 and make it "another pair in the same
column is in the Succeeded state."

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Apr 2017 18:29:57 +0000

Hi,

Initially, before the checks begin, only the topmost pair for each foundation is set to waiting.

Regards,

Christer

From: Ice [mailto:[email-masked]] On Behalf Of Taylor Brandstetter
Sent: 24 April 2017 20:02
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt

Yes; when I was typing up the example I hadn't noticed that the "each component of the media stream" part had been removed from 5245bis.

I think you could merge cases 2 and 3 and make it "another pair in the same column is in the Succeeded state."

On Sun, Apr 23, 2017 at 2:57 PM, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>> wrote:

Thanks for the example.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Apr 2017 21:05:59 -0600

> same column is in the Succeeded state." 

Maybe. I'll look at that more closely in the next day or two...

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Apr 2017 11:20:13 +0000

Hi,

In general, if something is unclear in 5245bis, please let the authors know. One of the main reasons for doing 5245bis in the first place is to clarify the procedures.

Regards,

Christer

From: Ice <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Monday 24 April 2017 at 21:29
To: Taylor Brandstetter <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt

Hi,

Regards,

Christer

From: Ice [mailto:[email-masked]] On Behalf Of Taylor Brandstetter
Sent: 24 April 2017 20:02
To: Peter Saint-Andre <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ice] Taylor's review of draft-ietf-ice-trickle-08.txt

Thanks for the example.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 25 Apr 2017 11:13:47 -0600

> Maybe. I'll look at that more closely in the next day or two...

If we only mention Succeeded, we would lose the part of Case 3 that
covers the Failed state...

Peter

---

From: Taylor Brandstetter <[email-masked]>
Date: Tue, 25 Apr 2017 15:16:09 -0700

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?

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 25 Apr 2017 16:35:20 -0600

>        column 5, row 1 succeeded and two newly formed pairs were placed in

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

Peter