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

[Christer Holmberg <[e-mail]>]

Hi,

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

Perhaps it could be more clear, but there is text:

Section 11.1.1 says:

   "Agents always send media using a candidate pair, using candidate
   pairs in the VALID LIST.  Once a candidate pair has been selected
   only that candidate pair (referred to as selected pair) is used for
   sending media."

>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. 

There is no text mandating the paths to match prior to nomination.

>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. 

While I guess it would technically be possible, I don't think that's the intention. 

Every now and then there have been discussion about never nominating, allowing usage of multiple valid pairs. But, if using multiple valid pairs is something people want to do I think we should properly specify how it is done, so that people don't have to do it using hacks.

> 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...

The reason is that entities can release resources.

>, nor are all the magical powers restored by the re-nomination document.

Re-nomination does not mean (AFAIU) that you suddenly can start switching between valid pairs - it means that you change the one valid pair that you are going to use for media.

>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, 

I think it's still good to explicitly say that endpoints are allowed to release resources.

Also, after some thinking, I am not sure a re-nomination really would need consent. If the peer responds to a nomination STUN request it means it accepts the (re-)nomination. 

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

I'll let others speak on behalf of the re-nomination document. In my understanding, 5245bis currently implies, once nomination occurs: 1, 2* and 5.

* Section 11.2 contains the following text:

   "Even though ICE agents are only allowed to send media using valid
   candidate pairs (and, once a candidate pair has been selected, only
   on the selected pair) 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."

I think that text is confusing. After a pair has been selected, an endpoint should not have be prepared to receive media on any of the candidiates. 

Regards,

Christer




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