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

[Bernard Aboba <[e-mail]>]

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