Subject: [MMUSIC] trickle-ice review

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 06 Jul 2015 22:01:06 -0600

Because I'll probably be on a plane (not to Prague!) during the MMUSIC 
session on July 22, I figured it might be helpful to post some comments 
to the list.

Abstract...

OLD
    The above mechanism is also referred to as "trickle ICE".

NEW
    This mechanism is called "trickle ICE".

Rationale: the mechanism is never referred to as anything other than 
trickle ICE.

Section 1...

A typo:

OLD
    describes mechanisms for gathering, candidates, prioritizing them,

NEW
    describes mechanisms for gathering candidates, prioritizing them,

[I found some other typos here and there but haven't noted them - our 
friends on the RFC Editor team can help later on.]

Section 4...

This sounds a bit strange, as if RFC 5245 talks about support for trickle:

    According to [RFC5245] every time an agent supporting trickle ICE
    generates an offer or an answer, it MUST include the "trickle" token
    in the ice-options attribute.

I suggest:

    According to [RFC5245], supported features MUST be advertised in the
    ice-options attribute.  Therefore an agent supporting trickle ICE
    MUST include a token of "trickle" in the ice-options attribute every
    time it generates an offer or an answer.

Section 5...

I question this statement:

    For optimal performance, it is RECOMMENDED that an initial offer
    contains host candidates only.  This would allow both agents to start
    gathering server reflexive, relayed and other non-host candidates
    simultaneously, and it would also enable them to begin connectivity
    checks.

As we have discovered recently (see the research the Philipp Hancke has 
been performing on deployed WebRTC audio/video services), the best call 
setup time and thus user experience is found by sending only relayed 
candidates first. Recommending that user agents send only host 
candidates in the initial offer will only perpetuate slow call setup times.

Section 6.1...

    An agent can respond to an initial offer at any point while gathering
    candidates.  The answer can again contain any set of candidates
    including none or all of them.  Unless it is protecting host
    addresses for privacy reasons, the agent would typically construct
    this initial answer including only them, thus allowing the remote
    party to also start forming checklists and performing connectivity
    checks.

By "them" I assume you mean host candidates. If so, see above on the 
"host-only-first" policy.

Section 8...

    For the most part, trickle ICE agents perform connectivity checks
    following vanilla ICE procedures.  Of course, the asynchronous nature
    of candidate harvesting in trickle ICE would impose a number of
    changes described here.

Actually I think it is not just harvesting but communication.

Section 9.3...

    Once an agent sends the end-of-candidates event, it will update the
    state of the corresponding check list as explained in section
    Section 8.1.  Past that point agents MUST NOT send any new
    candidates.  Once an agent has received an end-of-candidates
    indication, it MUST also ignore any newly received candidates for
    that media stream.  Adding new candidates to the negotiation is hence
    only possible through an ICE restart.

The second sentence is somewhat at odds with the last sentence. I 
suggest saying something like "Past that point agents MUST NOT send any 
new candidates within this ICE session" or some such.

I have not yet formed an opinion on the open issues described in 
Appendix A, nor have I yet had a chance to check that the XMPP Jingle 
use of trickled candidates (which dates from 2005!) is fully consistent 
with draft-ietf-mmusic-trickle-ice. I will try to complete those tasks 
before the Prague meeting.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 Jul 2015 00:53:06 -0700

On Jul 6, 2015, at 9:16 PM, Peter Saint-Andre - &yet <[email-masked]> wrote:
> As we have discovered recently (see the research the Philipp Hancke has been performing on deployed WebRTC audio/video services), the best call setup time and thus user experience is found by sending only relayed candidates first.

[BA] This result has been known for quite some time - and provides an argument that the recommended priority formula is sub-optimal. However, the question is what to do if relay candidates are not yet available, but host candidates are. Are you saying it is optimal to wait and trickle relay candidates??

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 07 Jul 2015 08:15:40 -0600

On 7/7/15 1:53 AM, Bernard Aboba wrote:
>> As we have discovered recently (see the research the Philipp Hancke
>> has been performing on deployed WebRTC audio/video services), the
>> best call setup time and thus user experience is found by sending
>> only relayed candidates first.
>
> [BA] This result has been known for quite some time - and provides an
> argument that the recommended priority formula is sub-optimal.
> However, the question is what to do if relay candidates are not yet
> available, but host candidates are. Are you saying it is optimal to
> wait and trickle relay candidates??

The current text doesn't cover any of those nuances:

But we know that, if relay candidates *are* available, it is not optimal 
for the initial offer to contain host candidates only. So the 
categorical text in the document isn't right, I think.

One approach would be to cover the nuances (if you have a relayed 
candidate, send just that in the initial offer - but if not then send 
only host candidates).

Another approach would be to say "immediately send whatever candidates 
you already know about in the initial offer because this enables both 
agents to start gathering additional candidates and performing 
connectivity checks". That seems to be what the current text is actually 
trying to say. Then leave the issue of host vs. relayed out of the mix 
here because I think that's a separate issue and not specific to trickle 
ICE.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Emil Ivov <[email-masked]>
Date: Mon, 13 Jul 2015 21:34:38 -0500

On Tue, Jul 7, 2015 at 9:15 AM, Peter Saint-Andre - &yet
<[email-masked]> wrote:
>    contains host candidates only.  \

Indeed, this should say "none" or host candidates only!

As to whether or not relay would be the only available candidates,
that's an application choice. Host candidates are always faster to
gather and there are many cases where they would also be just as or
more reliable than relay ones.

Cheers,
Emil

> This would allow both agents to start
> But we know that, if relay candidates *are* available, it is not optimal for
> the initial offer to contain host candidates only. So the categorical text
> in the document isn't right, I think.
>
> One approach would be to cover the nuances (if you have a relayed candidate,
> send just that in the initial offer - but if not then send only host
> candidates).
>
> Another approach would be to say "immediately send whatever candidates you
> already know about in the initial offer because this enables both agents to
> start gathering additional candidates and performing connectivity checks".
> That seems to be what the current text is actually trying to say. Then leave
> the issue of host vs. relayed out of the mix here because I think that's a
> separate issue and not specific to trickle ICE.
>
> Peter
>
> --
> Peter Saint-Andre
> https://andyet.com/
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
https://jitsi.org