Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-trickle-18: (with COMMENT)

[Christer Holmberg <[e-mail]>]

Hi,

>>> Important comments:
>>>    agent SHOULD follow a policy of keeping the higher priority candidate
>>>    unless it is peer reflexive.
>>>
>>> IMPORTANT: This section is confusing wrt how pruning works. AIUI, you 
>>>> follow ordinary 5245 pruning procedures at the beginning of the 
>>> connection for whatever candidates you have. Is that incorrect?
>> 
>> Right, there's no reason to override normal pruning procedures.
>> 
>>>> Also, why are you proposing prioritizing other candidates over prflx 
>>> candidates? That's not the procedure in 5245.
>> 
>> This text was in the spec when I joined the author team. I am not sure 
>> of the rationale. The only difference with Trickle ICE is handling 
>> candidate pairs that come in later. Section 13 notes that it's 
>> possible for a server reflexive candidate to be perceived as peer 
>> reflexive if the STUN connectivity check arrives before signaling of 
>> the trickled candidate, however it also notes that this "does not 
>> require any change in processing". See also below.
>> 
>>>    maximum number of candidate pairs (100 by default as per
>>>    [rfc5245bis]), the new pair is discarded.
>>>
>>> IMPORTANT: Why are you discarding before you check for redundancy?
>>> This seems like it evicts the wrong pair.
>> 
>> Hmm, it could. Checking the max-pair rule after the redundancy check 
>> would indeed make more sense.
>> 
>>>    new candidate to the priority of the pre-existing candidate and then
>>>    re-sorting the check list.
>>> IMPORTANT: This seems to slow down checks if the existing check is 
>>> already running. What is the rationale for this?
>> 
>> Good point. This is the same issue with prflx in another guise. I'm 
>> not sure of the rationale. The only thing I can come up with is that 
>> we're trying to work around the fact that some server reflexive 
>> candidates could be perceived initially as peer reflexive. Throwing 
>> out the earlier "peer reflexive" candidate in favor of the later 
>> candidate (which might be server reflexive) might be a workaround.
>> 
>> I'll ask Emil to clarify this for us.
>
> Emil and I synced up just now.
>
> Right after IETF 95, Taylor Brandstetter raised an issue about the handling of peer reflexive candidates 
> during de-duplication, quoted here for convenience from the mail archive (see
> https://www.ietf.org/mail-archive/web/ice/current/msg00304.html):
>
> ###
>
> It's possible for a remote peer reflexive candidate to be created simply because a binding request was received 
> before the candidate was signaled. Then, according to this rule, the peer reflexive candidate would not be replaced 
> by the server reflexive candidate when it's signaled, because the peer reflexive candidate is guaranteed to have a higher priority.
>
> As a result, the endpoints will prioritize the same candidate pair differently, because one endpoint sees the candidate 
> as peer reflexive while the other sees it as something else. This means the endpoints could have different ideas of which 
> candidate pair is the highest priority, which could result in sub-optimal selection of a candidate pair, or asymmetric selection 
> if the controlling agent is an RFC 5245 endpoint that uses aggressive nomination.
>
> So, I suggest a minor modification to the rule: peer reflexive candidates are always replaced by other types of candidates, regardless of priority.
>
> ###
>
> Looking back at the text we recently removed in -19, I'm not convinced that we ever captured Taylor's feedback properly. I will 
> look into it more carefully later today or over the weekend and propose a further text adjustment.

Not sure I follow. Is this a binding-request-was-received-before-the-candidate-was-signaled case specific to trickle? Are we talking about trickled candidates?

If so, does it below to section 7? In another email I asked for clarification whether section 7 only applies to the initial check list (as section 8 seems to cover the case when candidates are later trickled).

Regards,

Christer