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

[Bernard Aboba <[e-mail]>]

Christer said:

"The irony is that "ice2" is used to prevent a legacy ICE peer from using
aggressive nomination. But, isn't allowing re-nomination more or less
bringing "aggressive nomination" back? :)"

[BA] I think we need to carefully examine the implications of "passive
aggressive" as well as the meaning of "nomination" in RFC 5245bis and make
sure that the meaning (and its implications) of these notions are
articulated.

*Prior* to nomination, I believe that RFC 5245bis allows both the
controlling and controlled sides to select validated pairs to send media
on, and permits *either side* to switch between validated pairs.  I don't
think this is said explicitly anywhere, but it is true, isn't it?

Wouldn't that also imply that the return path doesn't have to match the
sending path?  Again, not said anywhere explicitly, but it seems like it
would be the case.

That would also seem to imply that prior to nomination we have the
flexibility for implementations to support mujlti-path RTP? (e.g. sending
different RTP flows using different candidate pairs). Again, not said
explicitly anywhere.

Then somehow, *after* nomination, many of these magical properties vanish,
for reasons that I find hard to justify.   Again, the reasoning behind this
is not explained in RFC 5245bis, nor are all the magical powers restored by
the re-nomination document.

The problem I think arises from a full articulation of the meaning of
"nomination" in RFC 5245bis.

For example, if we are removing the concept of resource release from
nomination and basing it on consent instead, we need to explain the meaning
of "nomination" encapsulated in the negotiation of "ice2".  Which of the
following statements are implied by "nomination"?

1.  "I want to use this pair (and only this pair) to send"
2. "I want to receive using this pair (and only this pair)"
3. "I have selected a set of validated pairs for sending and will request
consent for them"
4. "I have granted consent for a set of pairs suitable for receiving"
5. "The controlled side can release candidates that are neither receiving
or sending consent requests"?

Right now, it is not clear to me which of these statements are implied by
RFC 5245bis (or which ones are implied by the renomination document).



On Sat, Sep 2, 2017 at 4:00 AM, Christer Holmberg <
[e-mail]> wrote:

> Hi
>
> > [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.
>
> The irony is that "ice2" is used to prevent a legacy ICE peer from using
> aggressive nomination. But, isn't allowing re-nomination more or less
> bringing "aggressive nomination" back? :)
>
> Regards,
>
> Christer
>