Subject: Re: [Ice] Trickle ICE review

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 9 Apr 2017 15:42:11 -0600

Agreed. The authors will submit a new version soon that addresses
Taylor's feedback.

On 3/31/17 4:03 PM, Peter Thatcher wrote:
> Ah, thanks for explaining this.  I like your idea of making the real
> intention explicit (pair and trickle in the same order).  I think that's
> much more clear and precise.
> 
> 
> 
> 
> 
> On Thu, Mar 30, 2017 at 8:45 PM Taylor Brandstetter <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>         In the phrase " A Trickle ICE agent MUST NOT pair a local
>         candidate until it has been trickled to the remote agent.", what
>         does "has been trickled" mean?
> 
> 
>     Sorry I'm late at responding to this, but I assumed the main
>     intention here was that candidates are paired in the same order that
>     they're trickled, because that was necessary for the unfreezing
>     logic to work. For example: suppose an endpoint already has remote
>     candidates, and then gathers RTP and RTCP candidates. It pairs them
>     in the order "RTCP, RTP" (maybe the STUN response for the RTCP
>     candidate came back first), resulting in an RTCP pair being unfrozen
>     first, but they're trickled in the order "RTP, RTCP" (as a result of
>     the restrictions of section 16), resulting in the remote endpoint
>     unfreezing the RTP pair first.
> 
>     Before, this would have resulted in things failing (as I recall).
>     But this isn't as much of a problem now; I'm looking at the current
>     section 8.1.1, and it would result in the local endpoint just
>     unfreezing /both/ pairs, so things would be able to proceed.
> 
>     But it still could result in extra pairs being unfrozen; is that
>     acceptable? If not, I'd suggest moving this note to section 16, and
>     making it more clear what the intention is. For example: "Candidates
>     MUST be paired, following the procedures in section 8.1.1, in the
>     same order that they're trickled."
> 
>     An important related question: There used to be a line that said
>     "When trickle updates are sent, each candidate MUST be delivered to
>     the receiving Trickle ICE implementation ... in the same order that
>     they were sent." But the "in the same order that they were sent"
>     part has been removed. Do we no longer require that the signaling
>     mechanism preserves ordering? If so, Section 16 doesn't make sense
>     any more; it requires a specific order of candidate trickling, but
>     that can't be guaranteed if the signaling mechanism doesn't preserve
>     ordering. All my ramblings above would be moot as well.
> 
>     On Thu, Mar 30, 2017 at 10:53 AM, Christer Holmberg
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi,
> 
>         Perhaps we could say something like "re-start or once all
>         candidates have been released", or something like that... We
>         seem to agree, so it's just about wording :)
> 
>         Regards,
> 
>         Christer
> 
>         -----Original Message-----
>         From: Peter Saint-Andre [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         Sent: 30 March 2017 20:42
>         To: Peter Thatcher <[email-masked]
>         <mailto:[email-masked]>>; Christer Holmberg
>         <[email-masked]
>         <mailto:[email-masked]>>; Ari Keränen
>         <[email-masked] <mailto:[email-masked]>>
>         Cc: [email-masked] <mailto:[email-masked]>
>         Subject: Re: [Ice] Trickle ICE review
> 
>         On 3/30/17 9:45 AM, Peter Thatcher wrote:
>         > Ah, I see what you mean now.
>         >
>         > In that case, could we just define "ICE session" as the
>         something like
>         > "stuff until the next ICE restart or the termination of all ICE
>         > activity by this agent"?
> 
>         Right, there's no "ICE session termination" message, so that'll
>         have to do.
> 
>         Peter
> 
>         _______________________________________________
>         Ice mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/ice
>

---

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

On 3/30/17 9:45 PM, Taylor Brandstetter wrote:
>     In the phrase " A Trickle ICE agent MUST NOT pair a local candidate
>     until it has been trickled to the remote agent.", what does "has
>     been trickled" mean?
> 
> 
> Sorry I'm late at responding to this, but I assumed the main intention
> here was that candidates are paired in the same order that they're
> trickled, because that was necessary for the unfreezing logic to work.
> For example: suppose an endpoint already has remote candidates, and then
> gathers RTP and RTCP candidates. It pairs them in the order "RTCP, RTP"
> (maybe the STUN response for the RTCP candidate came back first),
> resulting in an RTCP pair being unfrozen first, but they're trickled in
> the order "RTP, RTCP" (as a result of the restrictions of section 16),
> resulting in the remote endpoint unfreezing the RTP pair first.
> 
> Before, this would have resulted in things failing (as I recall). But
> this isn't as much of a problem now; I'm looking at the current section
> 8.1.1, and it would result in the local endpoint just unfreezing
> /both/ pairs, so things would be able to proceed.
> 
> MUST be paired, following the procedures in section 8.1.1, in the same
> order that they're trickled."

WFM.

> An important related question: There used to be a line that said "When
> trickle updates are sent, each candidate MUST be delivered to the
> receiving Trickle ICE implementation ... in the same order that they
> were sent." But the "in the same order that they were sent" part has
> been removed. Do we no longer require that the signaling mechanism
> preserves ordering? If so, Section 16 doesn't make sense any more; it
> requires a specific order of candidate trickling, but that can't be
> guaranteed if the signaling mechanism doesn't preserve ordering. All my
> ramblings above would be moot as well.

This was changed between -04 (September 206) and -05 (January 2017). We
received quite a bit of feedback in that time period (e.g., Bernard
Aboba did a thorough review) and I would need to look at the specifics
more carefully to determine why we removed the clause "and in the same
order that they were sent". However, I think it's a reasonable
requirement to place on a signaling protocol, so I'd be fine with
re-adding in Section 8 ("Discovering and Sending Additional Local
Candidates") and mentioning it in Section 15 ("Requirements for
Signaling Protocols").

Peter