Re: [Ice] Trickle ICE review

[Peter Saint-Andre <[e-mail]>]

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

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