Re: [Ice] I-D Action: draft-ietf-ice-trickle-20.txt

[Christer Holmberg <[e-mail]>]

Hi Peter,

It’s up to you how to handle the administrative, but I think it would be useful to be able to see your suggested changes (e.g., using a pull request, or an email describing the changes) before submitting a new version of the draft.

Regards,

Christer


Sent from my iPhone

On 14 Apr 2018, at 1.43, Peter Saint-Andre <[e-mail]<mailto:[e-mail]>> wrote:

On 4/12/18 4:44 AM, Christer Holmberg wrote:

Hi,

I had a look at this, and I think there are another issues regarding
referencing section 5.1.3 (in addition to the fact that section 5.1.3 of
5245bis talks about candidates - not candidates pairs- as I mentioned in
another reply).

Section 5.1.3 defines procedures when gathering local candidates - NOT
when receiving remote candidates. And, as far as I remember, 5245bis does
not talk about eliminating of remote candidates (it does talk about check
list pruning, but that¹s a separate thing).

So, I think the text in bullet 4 of section 11 is wrong - it should not
reference section 5.1.3 of 5245bis. Instead it should say something like:

   4. The agent prunes the updated check list by following the rules
   in Section 6.1.2.4 of [rfc5245bis], but only checks existing pairs
   if they have a state of Waiting or Frozen (thus avoiding removal of
   pairs for which connectivity checks are in flight or for which
   connectivity checks have already yielded a definitive result).

Agreed, this shouldn't reference 5.1.3 at all.

In general, when we talk about removing redundant pairs, I think we should
use ³prune² terminology.

Agreed.

Also, I don¹t think ³in flight checks² is terminology defined in ICE, or
STUN in general.

Does that matter?

* In §11, the order of points 4 and 5 could be interpreted to mean that
a Trickle ICE agent aapplies the redundancy checking rules from 5245bis
and only then applies the rule in point 5 about pairs with peer
reflexive candidates.

So, what change do you suggest?

Most likely swap the order of 4 and 5, with some slight wordsmithing.

* Also in §11 (and §10 too), point 6 says:

 6.  If after the relevant redundancy tests the check list where the
     pair is to be added already contains the maximum number of
     candidate pairs (100 by default as per [rfc5245bis]), the agent
     SHOULD discard any pairs in the Failed state to make room for the
     new pair.  If there are no such pairs, the agent SHOULD discard
     the new pair.

Discarding the new pair is not consistent with §6.1.2.5 of 5245bis;
instead, we should discard lower-priority pairs to prune things down to
the maximum number of candidate pairs.

Do we want to discard lower-priority pairs even if they are in ³Succeeded²
or ³In-Progress² state?

No, those pairs are already carved out by the rule that the agent "only
checks existing pairs if they have a state of Waiting or Frozen".

I'll work on specific text and perhaps publish -21 over the weekend.

Peter