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

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

On 4/8/18 1:58 PM, Christer Holmberg wrote:
> 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?

My reading of Taylor's original email is that this is about receiving
duplicate candidates through the trickling process:

   At IETF 95, the decision was made to choose the candidate with the
   higher priority if duplicate candidates are received (see:
   https://github.com/ice-wg/trickle/issues/6). However, I see a
   potential issue with this, specifically regarding peer reflexive
   candidates.

And specifically about receiving a binding request before receiving any
signaling of the candidate:

   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.

https://www.ietf.org/mail-archive/web/ice/current/msg00304.html

> 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).

Yes, I read all of your email messages. :-)

I agree that the exact roles of Section 7 and Section are slightly
murky, and will propose better text today.

Peter