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

[Peter Thatcher <[e-mail]>]

Oops, hit send too soon.

That's what
https://www.ietf.org/archive/id/draft-thatcher-ice-renomination-01.txt does:
it negotiates "renomination".  And that's what Chrome's implementation of
WebRTC does.

On Wed, Aug 30, 2017 at 9:26 AM Peter Thatcher <[e-mail]> wrote:

> As far as "just enough" so that it isn't a hindrance: that's why I wanted
> to say that agents *may* switch.  It allows a renomination in the future.
> Saying they MUST NOT is a hindrance.  I would be fine if the *may* requires
> negotiation.  That's what
>
> On Wed, Aug 30, 2017 at 9:08 AM Bernard Aboba <[e-mail]>
> wrote:
>
>> Peter said:
>>
>> "Your reasoning for saying that an agent can't switch candidate pairs is
>> that it prevents the remote side from being able to release resources.  But
>> the switching side would only switch if the candidate pair recently
>> received an ICE check response (in other words, it knows the candidate pair
>> works), in which case it knows that resources have not been released."
>>
>> [BA] There is a dicotomy between the situation prior to nomination and
>> after it that isn't explained well in RFC 5245bis.  Prior to nomination,
>> the agent can switch between validated candidate pairs, and hopefully we
>> can make the language clear enough so that this will work well.
>>
>> While the same logic applies after nomination as well (e.g. it only makes
>> sense to switch a valid pair), the text doesn't clarify the meaning of
>> nomination with respect to resource release, nor does it talk about consent
>> (presumably the mechanism that would be used to maintain pair validity
>> after nomination), so that it's not clear how pair validity could be
>> maintained.  Since there is much RFC 5245 text still remaining, the overall
>> document reads as though while it represents an update to RFC 5245 it still
>> is based on a pre-WebRTC mindset.
>>
>> All this makes me wonder whether we should limit our aspirations for RFC
>> 5245bis to clarifying things "just enough" so that it isn't a hindrance.
>> People interested in building a modern ICE implementation for use in WebRTC
>> will probably focus more on Trickle-ICE, where implementation of consent
>> can be assumed, and perhaps the meaning of nomination within a WebRTC
>> context could be better explained.
>>
>>
>>
>> On Wed, Aug 30, 2017 at 11:19 AM, Peter Thatcher <[e-mail]>
>> wrote:
>>
>>> #2 and #3 are fine, but I'm not a fan of #1.
>>>
>>> Your reasoning for saying that an agent can't switch candidate pairs is
>>> that it prevents the remote side from being able to release resources.  But
>>> the switching side would only switch if the candidate pair recently
>>> received an ICE check response (in other words, it knows the candidate pair
>>> works), in which case it knows that resources have not been released.
>>>
>>> In other words, if the remote side chose to release resources, the local
>>> side wouldn't do the switch.  So the remote side is free to release
>>> resources; it's not prevented from doing so.  If it does, then the local
>>> side will notice and not do a switch.   But if the remote side doesn't
>>> release the resources, then the local side may switch.
>>>
>>> In other words, I think we can allow switching and resource release
>>> both.
>>>
>>> On Thu, Jul 27, 2017 at 4:01 AM Christer Holmberg <
>>> [e-mail]> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> Would anyone disagree with the following:
>>>>
>>>>
>>>>
>>>> 1)      explicitly indicating that re-nomination is **NOT** allowed
>>>> without ICE restart; and
>>>>
>>>> 2)      once a pair has been selected, agents need to be able to send *
>>>> *AND** receive media using that pair – but not using any other pair
>>>> (read: resources associated with other pairs may be released); and
>>>>
>>>> 3)      PRIOR to selection, agents need to be able to send **AND**
>>>> receive media on any valid pair (RFC 7675 adds restrictions, but that’s
>>>> outside the scope of 5245bis)
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>> *From:* Ice [mailto:[e-mail]] *On Behalf Of *Christer
>>>> Holmberg
>>>> *Sent:* 25 July 2017 10:17
>>>> *To:* Bernard Aboba <[e-mail]>
>>>> *Cc:* [e-mail]
>>>> *Subject:* Re: [Ice] Re-nomination and candidate pair switching in RFC
>>>> 5245bis
>>>>
>>>>
>>>>
>>>> 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:[e-mail]
>>>> <[e-mail]>]
>>>> *Sent:* 25 July 2017 02:29
>>>> *To:* Christer Holmberg <[e-mail]>
>>>> *Cc:* [e-mail]
>>>> *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:
>>>>
>>>>
>>>>
>>>>    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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> >[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):
>>>>
>>>> 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 :)
>>>>
>>>> >   NOTE: A controlling agent that does not support this specification
>>>> >   (i.e. it is implemented according to RFC 5245) might nominate more
>>>> >   than one candidate pair.  This was referred to as aggressive
>>>> >   nomination in RFC 5245.  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].  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.
>>>>
>>>> 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 <
>>>> [e-mail]> wrote:
>>>>
>>>> Hi
>>>> ,
>>>> >[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):
>>>>
>>>> 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 :)
>>>>
>>>> >   NOTE: A controlling agent that does not support this specification
>>>> >   (i.e. it is implemented according to RFC 5245) might nominate more
>>>> >   than one candidate pair.  This was referred to as aggressive
>>>> >   nomination in RFC 5245.  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].  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.
>>>>
>>>> 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 <
>>>> [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.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ice mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ice
>>>>
>>>
>>