Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol
draft-ietf-ice-trickle-21

[Ballot comment]
[DISCUSS regarding document reference issue removed -- this document will probably not need to change to address the issue]

This document appears to generally be in good shape. I have some fairly minor
comments.

---------------------------------------------------------------------------

§11:

>  signaling protocol in use.  When this happens, agents will use
>  [rfc5245bis] semantics to determine whether or not the new candidate
>  information require an ICE restart.

nit: "require"

---------------------------------------------------------------------------

§12:

> 12.  Unilateral Use of Trickle ICE (Half Trickle)

I find the use of the word "Unilateral" here to be confusing: the offering party
indicates support, and the answering party takes advantage of that support. I
would suggest using a different term ("Asymmetrical" maybe?); or, even more
simply, just replacing the entire section title with "Half Trickle".


---------------------------------------------------------------------------

§12:

The following passage indicates that the offer in a half-trickle situation might
not contain a full generation of candidates:

>  The initial ICE
>  description for half trickle would typically contain an end-of-
>  candidates indication, although this is not mandatory because if
>  trickle support is confirmed then the initiator can choose to trickle
>  additional candidates before it conveys an end-of-candidates
>  indication.

But then, two sentences later:

>  Because the initial ICE description contain a full
>  generation of candidates...

...which seems to contradict that indication.

(also, nit: "contains" rather than "contain")

---------------------------------------------------------------------------

§15:

>    a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx
>        raddr 2001:db8:a0b:12f0::1 rport 8998
>    a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx
>        raddr 2001:db8:a0b:12f0::1 rport 8998

[repeating a comment from draft-ietf-mmusic-trickle-ice-sip]

Thanks for the IPv6 example; however, I have a *lot* of heartburn with the
selection of an example that demonstrates IPv6 NAT behavior. Since ICE's srflx
behavior is fundamentally tied to IPv4 NATs (and should not be an issue with
IPv6, as NATs are unnecessary), I think it's okay for the srflx examples to go
ahead and show IPv4 addresses.

I *really* don't want to publish an RFC that demonstrates NATting of IPv6.

[Ballot comment]
UPDATED: I am recusing as I am an author. As the below are comments,
feel free to do whatever with them.

Comments in context: https://mozphab-ietf.devsvcdev.mozaws.net/D3650

I'm a listed author on this document, but I haven't worked on it in quite
some time, so this is read with mostly fresh eyes.


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?

Also, why are you proposing prioritizing other candidates over prflx candidates? That's not the procedure in 5245.

  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.

  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?


Other comments:

  Generation:  All of the candidates conveyed within an ICE session (as
      defined in [rfc5245bis]).

Note that "generation" isn't a 5245 term, so this text could be clearer.

  ICE Description:  Any session-related (as opposed to candidate-
      related) attributes required to configure an ICE agent.  These

It might be helpful to say "ICE session" to distinguish from session-level attributes in SDP

  for instance, the encoding for the Session Description Protocol (SDP)
  [RFC4566] is defined in [I-D.ietf-mmusic-trickle-ice-sip].

Note that this has the side effect of precluding agressive nomination

  consider the overall session to be under active negotiation as soon
  as possible.)
  As noted in Section 3, in application protocols that use SDP the

Why is this a benefit, actually? I see why it is in the offer so that you can parallelize the gathering on both sides, but why here?


  (rather than as a part of the initial ICE description or a response
  thereto), it is the responsibility of the using protocol to define
  methods for associating the indication with one or more specific data

I see here you say "using protocol" as opposed to "application"

  o  A signaling protocol SHOULD provide a way for parties to advertise
      and discover support for Trickle ICE before an ICE session begins

And here you use "signaling protocol" rather than "using protocl"

  To achieve this, when trickling candidates, agents MUST respect the
  order of components as reflected by their component IDs; that is,

I'm surprised to see a MUST paired with "While not crucial"

[Ballot comment]
Even though I am happy to see IPv6 examples, I share Adam's concern about using IPv6 with srflx being seen as an implicit endorsement of IPv6 NATs.

[Ballot discuss]
This document is part of the multi-document problem I flag in my DISCUSS on draft-ietf-mmusic-trickle-ice-sip, and needs to block on finding a solution to that issue.

[Ballot comment]
This document appears to generally be in good shape. I have some fairly minor
comments.

---------------------------------------------------------------------------

§11:

>  signaling protocol in use.  When this happens, agents will use
>  [rfc5245bis] semantics to determine whether or not the new candidate
>  information require an ICE restart.

nit: "require"

---------------------------------------------------------------------------

§12:

> 12.  Unilateral Use of Trickle ICE (Half Trickle)

I find the use of the word "Unilateral" here to be confusing: the offering party
indicates support, and the answering party takes advantage of that support. I
would suggest using a different term ("Asymmetrical" maybe?); or, even more
simply, just replacing the entire section title with "Half Trickle".


---------------------------------------------------------------------------

§12:

The following passage indicates that the offer in a half-trickle situation might
not contain a full generation of candidates:

>  The initial ICE
>  description for half trickle would typically contain an end-of-
>  candidates indication, although this is not mandatory because if
>  trickle support is confirmed then the initiator can choose to trickle
>  additional candidates before it conveys an end-of-candidates
>  indication.

But then, two sentences later:

>  Because the initial ICE description contain a full
>  generation of candidates...

...which seems to contradict that indication.

(also, nit: "contains" rather than "contain")

---------------------------------------------------------------------------

§15:

>    a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx
>        raddr 2001:db8:a0b:12f0::1 rport 8998
>    a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx
>        raddr 2001:db8:a0b:12f0::1 rport 8998

[repeating a comment from draft-ietf-mmusic-trickle-ice-sip]

Thanks for the IPv6 example; however, I have a *lot* of heartburn with the
selection of an example that demonstrates IPv6 NAT behavior. Since ICE's srflx
behavior is fundamentally tied to IPv4 NATs (and should not be an issue with
IPv6, as NATs are unnecessary), I think it's okay for the srflx examples to go
ahead and show IPv4 addresses.

I *really* don't want to publish an RFC that demonstrates NATting of IPv6.

[Ballot comment]
Thanks for the well written doc! On minor comment on the use of normative language:

Section 8: "Also, candidate trickling needs to be correlated to a specific ICE
  session, so that if there is an ICE restart, any delayed updates for
  a previous session can be recognized as such and ignored by the
  receiving party. "
Maybe use normative language here: "Also, candidate trickling MUST be correlated to a specific ICE
  session, so that if there is an ICE restart, any delayed updates for
  a previous session can be recognized as such and ignored by the
  receiving party. "
I assume this is not using normative language because there is a normative requirement in sec 14. However, not using normative language in both cases seems rather confusing to me. Alternatively , I would suggest to add a forward reference.

[Ballot discuss]
I haven't yet reviewed this document, but it is part of the multi-document problem I flag in my DISCUSS on draft-ietf-mmusic-trickle-ice-sip, and needs to block on finding a solution to that issue.

[Ballot comment]

Comments in context: https://mozphab-ietf.devsvcdev.mozaws.net/D3650

I'm a listed author on this document, but I haven't worked on it in quite
some time, so this is read with mostly fresh eyes.


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?

Also, why are you proposing prioritizing other candidates over prflx candidates? That's not the procedure in 5245.

  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.

  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?


Other comments:

  Generation:  All of the candidates conveyed within an ICE session (as
      defined in [rfc5245bis]).

Note that "generation" isn't a 5245 term, so this text could be clearer.

  ICE Description:  Any session-related (as opposed to candidate-
      related) attributes required to configure an ICE agent.  These

It might be helpful to say "ICE session" to distinguish from session-level attributes in SDP

  for instance, the encoding for the Session Description Protocol (SDP)
  [RFC4566] is defined in [I-D.ietf-mmusic-trickle-ice-sip].

Note that this has the side effect of precluding agressive nomination

  consider the overall session to be under active negotiation as soon
  as possible.)
  As noted in Section 3, in application protocols that use SDP the

Why is this a benefit, actually? I see why it is in the offer so that you can parallelize the gathering on both sides, but why here?


  (rather than as a part of the initial ICE description or a response
  thereto), it is the responsibility of the using protocol to define
  methods for associating the indication with one or more specific data

I see here you say "using protocol" as opposed to "application"

  o  A signaling protocol SHOULD provide a way for parties to advertise
      and discover support for Trickle ICE before an ICE session begins

And here you use "signaling protocol" rather than "using protocl"

  To achieve this, when trickling candidates, agents MUST respect the
  order of components as reflected by their component IDs; that is,

I'm surprised to see a MUST paired with "While not crucial"

[Ballot comment]
Please consider using the RFC 8174 boilerplate to supplement RFC 2119.

Section 5 implies that plain ICE includes a provision for an ICE description
with no candidates, but I'm failing to find that reference.  The rfc5245bis draft seems
to always assume that there will be at least a host candidate.
Is perhaps a different reference intended?

In section 8.2:

  o  As a standalone notification (e.g., after STUN Binding requests or
      TURN Allocate requests to a server time out and the agent has is
      not actively gathering candidates)

s/has is/is/

Section 13 says that trickled candidate information may cause an ICE
restart using the 5245bis semantics, but I don't see anywhere in
5245bis that would have additional candidate information induce a
restart.  Is this the right reference?

Thanks for updating per the secdir review about the in-order requirement!
However, we currently have language about transmitting candidates/end-of-candidates
"not more than once", but we kind of do want exactly-once semantics for
end-of-candidates, unless ICE terminates normally prior to that.
Is there a good way to phrase that more clearly?

Maybe the last bullet of section 15 (must be able to send
end-of-candidates) should come earlier in the list, in particular before the
requirement for nonduplication and in-order.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-ice-trickle-16. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the ICE Options registry on the Interactive Connectivity Establishment (ICE) registry page located at:

https://www.iana.org/assignments/ice/

A single, new registration will be made as follows:

Name: trickle
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-02-22):

From: The IESG
To: IETF-Announce
CC: ben@nostrum.com, ice-chairs@ietf.org, Nils Ohlmeier , draft-ietf-ice-trickle@ietf.org, ice@ietf.org, nohlmeier@mozilla.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol) to Proposed Standard


The IESG has received a request from the Interactive Connectivity
Establishment WG (ice) to consider the following document: - 'Trickle ICE:
Incremental Provisioning of Candidates for the
  Interactive Connectivity Establishment (ICE) Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-02-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes "Trickle ICE", an extension to the
  Interactive Connectivity Establishment (ICE) protocol that enables
  ICE agents to send and receive candidates incrementally rather than
  exchanging complete lists.  With such incremental provisioning, ICE
  agents can begin connectivity checks while they are still gathering
  candidates and considerably shorten the time necessary for ICE
  processing to complete.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ballot/


No IPR declarations have been submitted directly on this I-D.

This is my AD evaluation of draft-ietf-ice-trickle-16.

The document is general well written and easy to follow. I have a few comments and questions I’d like to address prior to IETF LC.
——————————————————

- section 3, 2nd to last paragraph:

[Note: I already brought this up in a separate email, and Peter suggested a fix. I’m including it here for completeness]

This paragraph is written in terms of the SDP ice-options attribute. It should talk about the generic ICE option described in section 10 of 5245bis.

- 4, last sentence: “early as possible” seems a bit subjective for use with the SHOULD, especially since that will be very application depended. I imagine developers trying to decide if they should send an initial offer the second a user hovers over a contact (which may or may not be a good idea.) Please consider restating this without the 2119 SHOULD.

- 5, 2nd to last paragraph, last sentence: Should “fallback to [RFC3264]” be “fallback to non-ICE processing rules”?

-13, first sentence: "Either agent MAY convey subsequent candidate information at any time
  allowed by the signaling protocol in use.”

I’m a little confused by this, since previous text said you MUST NOT keep trickling after sending end-of-candidates. From the context of the section, I assume this is talking about future exchanges (e.g. a new offer) , not trickling as a result of a previous change, but the words seem ambiguous.

-16, 2nd paragraph: "Therefore a candidate for a specific component MUST NOT be conveyed prior to candidates for other components within the same foundation.”

I’m confused by this sentence; it seems like a deadlock where no component candidates can be conveyed first. Should “other components” be “earlier components”?

-16, paragraph after the SDP example: This seems to be an explanation of the example, not a normative statement. Please consider stating without the 2119 keywords.

-18: Please consider using the IESG (iesg@ietf.org) as the contact. I know we’ve had individual contacts for these in the past, but the iesg address is (hopefully) more stable than individual or WG addresses.

-19, 2nd paragraph:

Stephen’s SecDir review[1] of 5245bis asked for a stronger statement about the application’s ability to control control which network interfaces are exposed in ICE candidates.. It may be that having such a statement in 5245bis is enough, but don’t be surprised if it comes up in IETF LC or IESG review.

[1] https://mailarchive.ietf.org/arch/msg/ice/fyhuRfrMJqdnCJnE6MJ_0peMFsw

1. Summary

The document shepherd is Nils Ohlmeier. The responsible Area Director is Ben Campbell.

This document extends the Interactive Connectivity Establishment (ICE) by adding an option to ICE agents to send and receive candidates incrementally rather than exchanging a complete list. The working group is confident that this document is correctly classified on the Standards Track.

2. Review and Consensus
The extension is reasonably easy to add to an existing ICE implementation. Several independent implementations are deployed and are interoperable.
Though the number of reviews during Working Group Last Call was low, the document received quite a few reviews over its lifetime. No formal reviews are needed. The shepherd has no remaining concerns.

3. Intellectual Property
All authors have confirmed conformance with BCP 78 and 79.
There are no IPR disclosures referencing this document.

4. Other Points

Idnits points out three occurrences of 172.16.0.1 in the Appendix A section. As ICE is about NAT traversal it appears appropriate to leave this in a RFC1918 range and not use RFC 6890 addresses here.