Re: [Ice] Trickle ICE review

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 <deadbeef@google.com>
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 <
christer.holmberg@ericsson.com> 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:stpeter@stpeter.im]
Sent: 30 March 2017 20:42
To: Peter Thatcher <pthatcher@google.com>; Christer Holmberg <
christer.holmberg@ericsson.com>; Ari Keränen <ari.keranen@ericsson.com>
Cc: ice@ietf.org
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
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice