Subject: [Ice] Re-nomination and candidate pair switching in RFC 5245bis

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Jul 2017 05:21:53 -0700

During the ICE WG meeting today, there was discussion of whether RFC5245bis
should indicate that it is possible to re-nominate pairs (proposed by
Peter), or whether it is possible to switch from one interface to another
(Cullen).  While these capabilities are desirable, attempting to add them
to RFC 5245bis without negotiation has the potential to break
interoperability with existing RFC 5245 implementations.

In my experience, this is an area where RFC 5245 implementations have very
different interpretations. For example, some implementations (e.g. ones
that did not support aggressive) discard non-selected candidate pairs after
nomination. These implementations (e.g. particularly ones included in
previous product releases) cannot be assumed to change their behavior after
RFC 5245bis is published.  This raises the possibility that that
interoperability could be impacted.

Since in practice the desired candidate pair switching capabilities are
most likely to be supported in WebRTC implementations supporting Trickle
ICE, my recommendation is to think of candidate pair switching as a Trickle
ICE capability.   Since Trickle-ICE support is negotiated, clarifications
relating to candidate-pair switching can be linked to that negotiation.

This provides a potential way forward that bypasses potential
interoperability issues.  For example, if text on candidate-pair switching
is to be added to (either to RFC 5245bis or Trickle-ICE) then the text
could say that support for these behaviors can only be assumed if they are
explicitly negotiated. The Trickle-ICE document could then create normative
requirements for support of the new behaviors by stating that support for
them is mandatory when supporting full-Trickle.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Jul 2017 19:33:23 +0000

Hi Bernard,

Support of 5245bis is also negotiated, using the “ice2” ICE option.

Also, my understanding was that endpoints supporting RFC 7675 might maintain consent on pairs currently not used for media, in order to be able to re-nominate in case consent for the currently nominated pair expires. However, RFC 7675 does not explicitly say anything about that.

Regards,

Christer

From: Ice [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: 20 July 2017 14:22
To: [email-masked]
Subject: [Ice] Re-nomination and candidate pair switching in RFC 5245bis

During the ICE WG meeting today, there was discussion of whether RFC5245bis should indicate that it is possible to re-nominate pairs (proposed by Peter), or whether it is possible to switch from one interface to another (Cullen).  While these capabilities are desirable, attempting to add them to RFC 5245bis without negotiation has the potential to break interoperability with existing RFC 5245 implementations.

In my experience, this is an area where RFC 5245 implementations have very different interpretations. For example, some implementations (e.g. ones that did not support aggressive) discard non-selected candidate pairs after nomination. These implementations (e.g. particularly ones included in previous product releases) cannot be assumed to change their behavior after RFC 5245bis is published.  This raises the possibility that that interoperability could be impacted.

Since in practice the desired candidate pair switching capabilities are most likely to be supported in WebRTC implementations supporting Trickle ICE, my recommendation is to think of candidate pair switching as a Trickle ICE capability.   Since Trickle-ICE support is negotiated, clarifications relating to candidate-pair switching can be linked to that negotiation.

This provides a potential way forward that bypasses potential interoperability issues.  For example, if text on candidate-pair switching is to be added to (either to RFC 5245bis or Trickle-ICE) then the text could say that support for these behaviors can only be assumed if they are explicitly negotiated. The Trickle-ICE document could then create normative requirements for support of the new behaviors by stating that support for them is mandatory when supporting full-Trickle.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 24 Jul 2017 16:20:53 -0700

Christer said:

"Support of 5245bis is also negotiated, using the “ice2” ICE option."

[BA] RFC 5245bis Section 7.1.1 continues to imply a single selected pair:

   Eventually, there will be only a single nominated pair in the VALID
   LIST for each component.  Once the state of the CHECK LIST is set to
   Completed, that exact pair is selected by ICE for sending and
   receiving media for that component.

Based on that text, an implementation might still release resources (e.g.
unused TURN candidates) post-nomination. Given this, the "ice2" ICE option
doesn't address potential interoperability issues resulting from different
resource release behaviors (although it does clear indicate lack of support
for aggressive nomination):

   NOTE: A controlling agent that does not support this specification
   (i.e. it is implemented according to RFC 5245
<https://tools.ietf.org/html/rfc5245>) might nominate more
   than one candidate pair.  This was referred to as aggressive
   nomination in RFC 5245 <https://tools.ietf.org/html/rfc5245>.  The
usage of the 'ice2' ice option by
   endpoints supporting this specifcation should prevent such
   controlling agents from using aggressive nomination.

Christer also said:

"Also, my understanding was that endpoints supporting RFC 7675 might
maintain consent on pairs currently not used for media, in order to be able
to re-nominate in case consent for the currently nominated pair expires.
However, RFC 7675 does not explicitly say anything about that."

[BA] RFC 7675 Section 5 says:

   Initial consent to send traffic is obtained using ICE [RFC5245
<https://tools.ietf.org/html/rfc5245>].  An
   endpoint gains consent to send on a candidate pair when the pair
   enters the Succeeded ICE state.

Given this, an RFC 5245bis implementation might request consent to send to

multiple remote peer candidates, so as to keep them alive. However,

there is nothing in RFC 7675 that requires the responder to grant

consent for that.  For example, based on the text in RFC 5245bis

Section 7.1.1, a conforming implementation might well revoke

consent on local candidates other than the local candidate in the

selected pair.

On Fri, Jul 21, 2017 at 12:33 PM, Christer Holmberg <
[email-masked]> wrote:

> Also, my understanding was that endpoints supporting RFC 7675 might
> maintain consent on pairs currently not used for media, in order to be able
> to re-nominate in case consent for the currently nominated pair expires.
> However, RFC 7675 does not explicitly say anything about that.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Ice [mailto:[email-masked]] *On Behalf Of *Bernard Aboba
> *Sent:* 20 July 2017 14:22
> *To:* [email-masked]
> *Subject:* [Ice] Re-nomination and candidate pair switching in RFC 5245bis
>
>
>
> During the ICE WG meeting today, there was discussion of whether
> RFC5245bis should indicate that it is possible to re-nominate pairs
> (proposed by Peter), or whether it is possible to switch from one interface
> to another (Cullen).  While these capabilities are desirable, attempting to
> add them to RFC 5245bis without negotiation has the potential to break

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Jul 2017 23:33:03 +0000

Hi
,
>Based on that text, an implementation might still release resources (e.g. unused TURN candidates) post-nomination. Given this, the "ice2" ICE option doesn't address >potential interoperability issues resulting from different resource release behaviors (although it does clear indicate lack of support for aggressive nomination): 

The whole discussion began when I was given a comment that the text above should be modified, to clarify that the pair used for media can change after a pair has been selected.

But, if the outcome is that the pair can NOT change, maybe we need to clarify THAT instead :)

>   (i.e. it is implemented according to RFC 5245) might nominate more
>   nomination in RFC 5245.  The usage of the 'ice2' ice option by
>"Also, my understanding was that endpoints supporting RFC 7675 might maintain consent on pairs currently not 
>used for media, in order to be able to re-nominate in case consent for the currently nominated pair expires. However, 
>RFC 7675 does not explicitly say anything about that."
>
>   Initial consent to send traffic is obtained using ICE [RFC5245].  An

Sure - the responder is not mandated to grant consent to multiple candidates after nomination. But, the option to do seems to be there (unless I've understood the RFC wrong), and the only reason to do so would be possible re-nomination.

Anyway, I don't have any strong feelings which way we go, but we do need to make it clear in the spec whether re-nomination is allowed or not.

Regards,

Christer

On Fri, Jul 21, 2017 at 12:33 PM, Christer Holmberg <[email-masked]> wrote:
Hi Bernard,

 
Regards,
 
Christer

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 24 Jul 2017 17:28:34 -0700

Christer said:

"The whole discussion began when I was given a comment that the text above
should be modified, to clarify that the pair used for media can change
after a pair has been selected.

But, if the outcome is that the pair can NOT change, maybe we need to
clarify THAT instead :)"

[BA] Currently, use of the "ice2" ICE option forestalls use of aggressive
nomination (e.g. setting the nominated flag on more than one pair).  Since
only the selected pair can be used to send media, that would seem to rule
out changing the pair used for media after a pair has been selected:

   Once a candidate pair has been selected
   only that candidate pair (referred to as selected pair) is used for
   sending media.

What about changing the pair used for media prior to selection?  On this
point, the text seems less clear than it could be.

Prior to nomination, the specification allows the sending of media on a
successful pair:

   o  Once there is at least one nominated pair in the VALID LIST for
      every component of at least one media stream and the state of the
      CHECK LIST is Running:

...

      *  The agent MUST continue to respond to any checks it may still
         receive for that media stream, and MUST perform triggered
         checks if required by the processing of Section 6.3
<https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-10#section-6.3>.

      *  The agent MAY begin transmitting media for this media stream as

         described in Section 11.1
<https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-10#section-11.1>.

However, the specification is not clear enough about the receiving side;
while it recommends that implementations be prepared to receive prior to
nomination, it does not require this. From Section 11.2:

   ICE implementations SHOULD by default be
   prepared to receive media on any of the candidates provided in the
   most recent candidate exchange with the peer.

What happens if an implementation is NOT prepared to receive media?

In WebRTC, an implementation cannot send without consent, which

suggests that perhaps an unwilling receiver could use consent to

influence the potential sender.

However, the specification does not even reference RFC 7675,

so it is left unclear about how this is to be done.

For example, a receiver might not reply to a consent

request if the inability to receive is temporary ("I'm not ready yet"),

but that might cause consent to time out prior to nomination and

might even influence pair selection inappropriately.

Another choice might be to revoke consent (which would

invalidate the pair).  But that's pretty drastic unless the

pair is truly unacceptable.

unused TURN candidates) post-nomination. Given this, the "ice2" ICE option
doesn't address >potential interoperability issues resulting from different
resource release behaviors (although it does clear indicate lack of support
for aggressive nomination):

The whole discussion began when I was given a comment that the text above
should be modified, to clarify that the pair used for media can change
after a pair has been selected.

But, if the outcome is that the pair can NOT change, maybe we need to
clarify THAT instead :)

>"Also, my understanding was that endpoints supporting RFC 7675 might
maintain consent on pairs currently not
>used for media, in order to be able to re-nominate in case consent for the
currently nominated pair expires. However,
>consent on local candidates other than the local candidate in the

Sure - the responder is not mandated to grant consent to multiple
candidates after nomination. But, the option to do seems to be there
(unless I've understood the RFC wrong), and the only reason to do so would
be possible re-nomination.

Anyway, I don't have any strong feelings which way we go, but we do need to
make it clear in the spec whether re-nomination is allowed or not.

Regards,

Christer

On Mon, Jul 24, 2017 at 4:33 PM, Christer Holmberg <
[email-masked]> wrote:

> doesn't address >potential interoperability issues resulting from different
> The whole discussion began when I was given a comment that the text above
> should be modified, to clarify that the pair used for media can change
> after a pair has been selected.
>
> maintain consent on pairs currently not
> >used for media, in order to be able to re-nominate in case consent for
> the currently nominated pair expires. However,
> Sure - the responder is not mandated to grant consent to multiple
> candidates after nomination. But, the option to do seems to be there
> (unless I've understood the RFC wrong), and the only reason to do so would
> be possible re-nomination.
>
> Anyway, I don't have any strong feelings which way we go, but we do need
> to make it clear in the spec whether re-nomination is allowed or not.
>
> Regards,
>
> Christer
>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Jul 2017 08:17:20 +0000

Hi Bernard,

Regarding sending media PRIOR to nomination, we have previously agreed that any valid pair can be used for that. Perhaps it needs more clarification.

Regarding receiving media after nomination, it was discussed in Prague, as it is covered by Peter’s PR. I don’t have access to the PR/minutes right now, but I think the outcome was that an agent is only expected to receive media on the nominated pair (otherwise it cannot free resources).

Regards,

Christer

From: Bernard Aboba [mailto:[email-masked]]
Sent: 25 July 2017 02:29
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis

Christer said:

"The whole discussion began when I was given a comment that the text above should be modified, to clarify that the pair used for media can change after a pair has been selected.

But, if the outcome is that the pair can NOT change, maybe we need to clarify THAT instead :)"

[BA] Currently, use of the "ice2" ICE option forestalls use of aggressive nomination (e.g. setting the nominated flag on more than one pair).  Since only the selected pair can be used to send media, that would seem to rule out changing the pair used for media after a pair has been selected:

   sending media.

What about changing the pair used for media prior to selection?  On this point, the text seems less clear than it could be.

Prior to nomination, the specification allows the sending of media on a successful pair:

      CHECK LIST is Running:

...

         checks if required by the processing of Section 6.3<https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-10#section-6.3>.

      *  The agent MAY begin transmitting media for this media stream as
         described in Section 11.1<https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-10#section-11.1>.

However, the specification is not clear enough about the receiving side; while it recommends that implementations be prepared to receive prior to nomination, it does not require this. From Section 11.2:

Regards,

Christer

On Mon, Jul 24, 2017 at 4:33 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi
,

Regards,

Christer

On Fri, Jul 21, 2017 at 12:33 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bernard,

Regards,

Christer

From: Ice [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bernard Aboba
Sent: 20 July 2017 14:22
To: [email-masked]<mailto:[email-masked]>
Subject: [Ice] Re-nomination and candidate pair switching in RFC 5245bis