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

[Christer Holmberg <[e-mail]>]

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

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



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

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)?