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

From: [email-masked]
Date: Mon, 09 Apr 2018 16:42:26 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interactive Connectivity Establishment WG of the IETF.

        Title           : Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol
        Authors         : Emil Ivov
                          Eric Rescorla
                          Justin Uberti
                          Peter Saint-Andre
	Filename        : draft-ietf-ice-trickle-20.txt
	Pages           : 33
	Date            : 2018-04-09

Abstract:
   This document describes "Trickle ICE", an extension to the
   Interactive Connectivity Establishment (ICE) protocol that enables
   ICE agents to begin connectivity checks while they are still
   gathering candidates, by incrementally exchanging candidates over
   time instead of all at once.  This method can considerably accelerate
   the process of establishing a communication session.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ice-trickle-20
https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-20

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 9 Apr 2018 17:43:26 -0600

Some further edits along the lines discussed on list...

On 4/9/18 5:42 PM, [email-masked] wrote:
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 Apr 2018 15:27:46 -0600

Ekr and I looked at the peer reflexive text and found two things that
are easily fixed with some wordsmithing:

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

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

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Apr 2018 02:50:23 +0000

Hi Peter,

Don't know whether it is relevant to this issue, but on the previous version I commented that the procedures in section 5.1.3 of 5245bis is about eliminating candidates - not pairs. However, the text in draft-trickle still talks about pairs.

Regards,

Christer

-----Original Message-----
From: Ice [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: 11 April 2018 23:28
To: [email-masked]
Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-20.txt

Ekr and I looked at the peer reflexive text and found two things that are easily fixed with some wordsmithing:

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

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.

Peter

On 4/9/18 5:43 PM, Peter Saint-Andre wrote:
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at tools.ietf.org.
>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Apr 2018 10:44:48 +0000

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

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

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

>and only then applies the rule in point 5 about pairs with peer

So, what change do you suggest?

>the maximum number of candidate pairs.

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

Regards,

Christer

>>>         Title           : Trickle ICE: Incremental Provisioning of
>>>Candidates for the Interactive Connectivity Establishment (ICE) Protocol
>>>         Authors         : Emil Ivov
>>>                           Eric Rescorla
>>>                           Justin Uberti
>>>                           Peter Saint-Andre
>>>submission

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 13 Apr 2018 16:43:12 -0600

>     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

Agreed.

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

Does that matter?

> So, what change do you suggest?

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

> Do we want to discard lower-priority pairs even if they are in ³Succeeded²

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

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 Apr 2018 06:51:26 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Agreed.

Does that matter?

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 Apr 2018 07:54:25 +0000

Hi,

...

>> Also, I don¹t think "in flight checks" is terminology defined in ICE, 
>> or STUN in general.
>
> Does that matter?

Why not use existing terminology? I assume you mean pairs in "In-Progress" state?

Something like:

       "(thus avoiding removal of pairs that have a state of In-Progress, and pairs for which
         connectivity checks have already yielded a definitive Sucessful or Failed result)."

...

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

True. I got confused due to the reference issue in bullet 5. I withdraw the question.

Regards,

Christer