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

[Bernard Aboba <[e-mail]>]

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 <
[e-mail]> wrote:

> 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:[e-mail]] *On Behalf Of *Bernard Aboba
> *Sent:* 20 July 2017 14:22
> *To:* [e-mail]
> *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.
>
>
>
>
>