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

[Bernard Aboba <[e-mail]>]

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.