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

From: Peter Thatcher <[email-masked]>
Date: Wed, 30 Aug 2017 15:19:00 +0000

#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 <
[email-masked]> 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:[email-masked]] *On Behalf Of *Christer Holmberg
> *Sent:* 25 July 2017 10:17
> *To:* Bernard Aboba <[email-masked]>
> *Cc:* [email-masked]
> *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:[email-masked]
> <[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:
>
>
>
>    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 <
> [email-masked]> 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 <
> [email-masked]> 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:[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.
>
>
>
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 30 Aug 2017 12:08:16 -0400

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 <[email-masked]>
wrote:

>> 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
>> "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.
>>
>> >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):
>>
>> >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):
>>
>> 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

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 30 Aug 2017 16:26:15 +0000

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 <[email-masked]>
wrote:

>>> [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:
>>>
>>>
>>>
>>> The whole discussion began when I was given a comment that the text
>>> The whole discussion began when I was given a comment that the text

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 30 Aug 2017 16:28:12 +0000

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 <[email-masked]> wrote:

>>>> What about changing the pair used for media prior to selection?  On
>>>> this point, the text seems less clear than it could be.
>>>>
>>>>
>>>>
>>>> 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:
>>>>
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>> 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: Bernard Aboba <[email-masked]>
Date: Wed, 30 Aug 2017 14:23:41 -0400

On Aug 30, 2017, at 12:28 PM, Peter Thatcher <[email-masked]> 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 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. 

[BA] It seems like the document would at least need to talk about consent to include a "may". As it is, negotiating "ice2" only means that you're talking to a slightly refurbished RFC 5245 implementation. That's like the difference between a new car with driver assist (a modern WebRTC ICE implementation with Trickle) and an Edsel that's been waxed and given an oil change.

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 30 Aug 2017 20:55:37 +0000

On Wed, Aug 30, 2017 at 11:23 AM Bernard Aboba <[email-masked]>
wrote:

> [BA] It seems like the document would at least need to talk about consent
> to include a "may". As it is, negotiating "ice2" only means that you're
> talking to a slightly refurbished RFC 5245 implementation. That's like the
> difference between a new car with driver assist (a modern WebRTC ICE
> implementation with Trickle) and an Edsel that's been waxed and given an
> oil change.
>

You always need to have consent to use a candidate pair.  I guess the
question you're asking is how recent does the consent need to be.  But I'm
not sure we need to standardize that.  If an implementation chooses to be
too aggressive about switching, it will send a path that doesn't work.  In
your analogy, you're worried about the driver assist doing something dumb
and crashing into the Edsel.  Well, don't ship a car that crashes.  Do we
need to standardize "don't switch to a candidate pair that doesn't work"
(AKA don't crash)?

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 30 Aug 2017 17:30:22 -0400

The problem as I understand it is that RFC 5245bis is intended to be usable by non-WebRTC implementations, so it cannot mandate (or even mention??) consent. 

If this seems silly to you (it does to me) maybe it would make more sense to assume RFC 5245bis is for use in a modern ICE implementation usable with WebRTC, because after all, isn't that what ICE developers should be working on???

That would make it possible for consent to be referenced and then the idea of keeping consent for non-nominated pairs after nomination could be introduced.

Just a thought.

> On Aug 30, 2017, at 4:55 PM, Peter Thatcher <[email-masked]> wrote:
> 
> 
> 
>> On Wed, Aug 30, 2017 at 11:23 AM Bernard Aboba <[email-masked]> wrote:
> You always need to have consent to use a candidate pair.  I guess the question you're asking is how recent does the consent need to be.  But I'm not sure we need to standardize that.  If an implementation chooses to be too aggressive about switching, it will send a path that doesn't work.  In your analogy, you're worried about the driver assist doing something dumb and crashing into the Edsel.  Well, don't ship a car that crashes.  Do we need to standardize "don't switch to a candidate pair that doesn't work" (AKA don't crash)?

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 Aug 2017 06:53:12 +0000

Hi,

>The problem as I understand it is that RFC 5245bis is intended to be usable by non-WebRTC implementations, so it cannot mandate (or even mention??) consent.

Correct.

However, one option would be to require consent in order to do switching. Then, before the switching takes place, an endpoint would have to get consent. And, if the remote peer has released the candidate the consent would fail, and the switch can’t be done.

>If this seems silly to you (it does to me) maybe it would make more sense to assume RFC 5245bis is for use in a modern ICE implementation usable with WebRTC, because after all, isn't that what ICE d…

I think we also want “legacy” implementations, that previously used non-ICE mechanisms, to migrate to ICE.

Regards,

Christer

On Aug 30, 2017, at 4:55 PM, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Aug 30, 2017 at 11:23 AM Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:
On Aug 30, 2017, at 12:28 PM, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Aug 30, 2017 at 9:26 AM Peter Thatcher <[email-masked]<mailto:[email-masked]>> 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 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.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 31 Aug 2017 07:37:07 -0400

Christer said:

"However, one option would be to require consent in order to do switching.
Then, before the switching takes place, an endpoint would have to get
consent. And, if the remote peer has released the candidate the consent
would fail, and the switch can’t be done."

[BA] That makes sense.

Question:  Is the list of post-nomination validated pairs solely chosen by
the controlling side maintaining consent on them?  Or can the controlled
side indicate an interest in retaining a validated pair by maintaining
consent on it as well? If so, would this imply that controlling and
controlled sides could send on different pairs?

On Thu, Aug 31, 2017 at 2:53 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> >The problem as I understand it is that RFC 5245bis is intended to be
> usable by non-WebRTC implementations, so it cannot mandate (or even
> mention??) consent.
>
> Correct.
>
> However, one option would be to require consent in order to do switching.
> Then, before the switching takes place, an endpoint would have to get
> consent. And, if the remote peer has released the candidate the consent
> would fail, and the switch can’t be done.
>
> >If this seems silly to you (it does to me) maybe it would make more sense
> to assume RFC 5245bis is for use in a modern ICE implementation usable with
> WebRTC, because after all, isn't that what ICE developers should be working
> on???
>
>>> negotiation.  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.
>>>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 Aug 2017 11:48:59 +0000

Hi,

>Christer said:
>
>"However, one option would be to require consent in order to do switching. Then, before the switching takes place, an endpoint would have to get consent. And, if the remote peer has released the candidate the consent would fail, and the switch can’t be done."
>
>[BA] That makes sense.
>
>Question:  Is the list of post-nomination validated pairs solely chosen by the controlling side maintaining consent on them?  Or can the controlled side indicate an interest in retaining a validated pair by maintaining consent on it as well? If so, would this imply that controlling and controlled sides could send on different pairs?

I guess the first question is: do you need to maintain consent? Or, is it enough to simply send keep-alive STUNs on the pairs that you’d like to maintain, and request consent when you are actually going to switch?

Also, are both endpoints allowed to switch? Or, do we consider a switch a re-nomination, in which case I assume only the controlling agent is allowed to do it?

Regards,

Christer

On Thu, Aug 31, 2017 at 2:53 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Correct.

Regards,

Christer