[MMUSIC] Review of draft-ietf-mmusic-trickle-ice-02

[Brandon Williams <[e-mail]>]

I've reviewed draft-ietf-mmusic-trickle-ice-02. Sorry for the delay 
since Prague.

First some nits, mostly in the introduction.

s 1, para 1
There's an extra comma I think.
s/gathering, candidates,/gathering candidates,/

s 1, para 2 and elsewhere
Does the term "candidate harvesting" come from somewhere specific? I 
don't find it in RFC5245. I would stick "candidate gathering" throughout 
for consistency with 5245 unless you mean something distinctly different 
by the term, in which case a definition is called for in section 2.

s 1, para 2
"Gathering candidates ... would often involve". I suggest just 
"Gathering candidates ... often involves"

s 1
The intro could benefit from a specific example of the lengthy session 
establishment time mentioned in para 3.

s1, para 4
It's just '... known as "trickle ICE"' I think, not 'also known as'.

s1, para 5
trickle ICE allows candidates of any type to be exchanged as soon as 
they've been discovered, right? Not just "exchange host candidates as 
soon as a session has been initiated".

s1, para 7
"needs to be" and "should operate" make the paragraph a little harder to 
read. I suggest "... how support for trickle ICE is discovered, how 
checklists are built and updated with trickle ICE, and how trickle ICE 
implementations interoperate with ..."

s 4, para 1
Seems to indicate that RFC5245 describes what a trickle ICE agent should 
do. Needs re-wording. I think you mean that there's a requirement in 
5245 that leads to the requirement stated here.

s 4.1
s/relay candidates/relayed candidates/

s 9.3
There's a redundant sentence in the first paragraph on page 16.
"Sending the indication is necessary in order to avoid ambiguities and
speed up ICE conclusion. This is necessary in order to avoid
ambiguities and speed up ICE conclusion."

Now for some (hopefully) more substantive comments.

s 3
I think the section on "Incompatibility with Standard ICE" comes too 
early. It's difficult to process because the doc has not yet introduced 
the details of how trickle ICE works. Also in this section, do you 
really mean to indicate that trickle ICE is "incompatible" with RFC5245? 
The first example simply appears to be pointing to a way in which 
trickle ICE differs from vanilla ICE.

s 4, para 2
I think the draft should probably say the offering agent "MUST NOT 
attempt trickle negotiation" if it doesn't know the remote peer supports 
trickle, as opposed to "is is important that ..."

s 4.1, para 1
The concept of "end-of-candidates indication" is introduced here without 
explaining it. In general, I think that describing Full Trickle 
completely before introducing Half Trickle would make it easier to 
follow the Half Trickle details.

s 4.1, para 1
It's not clear that it would ever make sense to send a Half Trickle 
offer without a complete candidate list and an end-of-candidates 
indication, since if trickle support is not confirmed, there would be no 
opportunity to send additional candidates and have the non-trickle peer 
use them for anything. Suggesting such an operation appears to 
contradict the earlier discussion in section 4.

s 4.1
The explanation of how Half Trickle can deliver more than half the 
benefit almost seems to indicate that there is no reason for a UA that 
gathers in response to UI cues to perform Full Trickle. Is that what you 
intend?

s 5
It might be good in the paragraph that says "agents MAY generate an 
offer that contains no candidates" to explain the benefit. I think its 
because of one or both of: 1) allows the offering agent to receive the 
remote agents initial candidate list sooner, and 2) it allows the 
answering agent to begin candidate gathering sooner.

s 5.1
Your use of "... would still need to ..." in the paragraph about sending 
no candidates indicates that the use of IP6 :: is a MUST when there is 
no suitable candidate to send in the initial offer, rather than a MAY.

s 6
I'm not sure what "Specifically, such verification would indicate lack 
of support when the offer contains no candidates." means here. I think 
you mean that the RFC%@$% support verification procedure would fail, but 
that it will not if trickle is supported. Is this the only change to the 
RFC5245 support verification procedure? And wouldn't it be better to 
specifically call out the required change(s) with MUST?

s 6.1
What would be the benefit of sending and answer with no candidates? Is 
this to avoid a timeout of some sort triggering on the offering peer? It 
might be helpful to implementers to give an example.

s 6.2
It's unclear to me why it's useful to monitor Active/Frozen state for 
check lists with no remote and/or local candidates. What is actually 
being monitored in? Or is this just meant to indicate than an empty 
checklist MUST/SHOULD be treated as frozen for the purpose of the frozen 
candidates algorithm?

s 9
Why does trickle ICE do something different than vanilla ICE regarding 
candidate redundancy and priority? Are there any possible negative 
consequences? If there's a reason to believe that this isn't a concern, 
it might be good to call it out.

s 9.1
Are there potential cases where limiting the maximum list of candidate 
pairs with trickle could result in a different list than vanilla ICE? 
For example, it seems that deciding on the candidate pairs after all 
gathering is complete may allow candidate priority to be taken into 
account more effectively than dropping new pairs regardless of priority 
as candidates trickle in.

s A.2
The document goes into some detail about the importance of unfreeze 
timing as part of ensuring that checks get through. This indicates to me 
that resolution of the question of when to unfreeze and start checks is 
critical to resolve.


That's it. Hope it's useful. Please let me know if any of these comments 
are unclear.

--Brandon
-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.