Subject: [Ice] Trickle: What is Section 16 about?

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Feb 2018 07:13:53 +0000

Hi,

Section 16 says the following:

   "To achieve this, when trickling candidates, agents MUST respect the
   order in which the components and streams appear (implicitly or
   explicitly) as they have been negotiated by means of the relevant
   candidate information.²

I can¹t parse this sentence. What ³order² is the text talking about?

   "Therefore candidates for a given component MUST NOT be conveyed prior
to 
    candidates for a component with a lower ID number within the same
foundation.²

Does it mean that, when an agent gathers a new candidate, it must not send
it to the peer in case there will later be a candidate with a lower ID
within the same foundation? I thought the whole idea of trickle was to
provide candidates to the peer in ³real-time², once they become available.

If the order in which candidates are placed in SDP matters, that should be
described in trickle-ice-sdp.

My suggestion would be to remove Section 16 completely, but I would like
someone to tell me why we need it, and what exactly it is trying to say :)

Regards,

Christer

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 28 Feb 2018 10:34:23 -0800

> within the same foundation?
>

That's how I interpret it; the example below explains how an RTCP candidate
for a particular foundation must be conveyed after (or simultaneously with)
the RTP candidate.

As for "why", I think that's explained by the paragraph above:

   One important aspect of regular ICE is that connectivity checks for a
>    specific foundation and component are attempted simultaneously by
>    both agents, so that any firewalls or NATs fronting the agents would
>    whitelist both endpoints and allow all except for the first
>    ("suicide") packets to go through.  This is also important to
>    unfreezing candidates at the right time.  While not crucial,
>    preserving this behavior in Trickle ICE is likely to improve ICE
>    performance.
>
>
Trickling candidates in a specific order helps guarantee that pairs are
formed in the same order by both peers, so that they'll perform
connectivity checks for the same pairs simultaneously.

Though given the updates to section 8.1.1 (Inserting a New Pair in a Check
List), this may not be as important as it used to be. The rules in 8.1.1
guarantee that the "topmost" pair for each foundation will always be
unfrozen. So I believe if candidates were trickled out of order, the worst
that could happen is that one peer ends up with more pairs unfrozen than
the other. For example:

1. Bob trickles RTCP candidate, then RTP.
2. Alice trickles RTP candidate, then RTCP.
3. Alice receives Bob's candidates, forming RTCP pair first (unfreezing
it), then RTP pair (unfreezing it too, since it becomes the new "topmost"
pair).
4. Bob receives Alice's candidates, forming RTP pair first (unfreezing it),
then RTCP pair (leaving it frozen).
5. Alice now has both pairs unfrozen, while Bob only has the RTP pair
unfrozen.

On Tue, Feb 27, 2018 at 11:13 PM, Christer Holmberg <
[email-masked]> wrote:

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