[MMUSIC] trickle-ice review

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

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/