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

[Christer Holmberg <[e-mail]>]

Peter (and others interested),

IF you want some change to the current behaviour, where a re-nomination is
NOT allowed, you need to participate in the discussion NOW. We are moving
towards WGLC, and we should close the window for technical changes
(non-bug fixing).

If I understood Bernard correctly, he was asking for having multiple
SIMULTANEOUS nominations, in order to do RTP multipath stuff etc. I
personally think that is outside the scope of 5245bis. I think the
question is whether we should allow re-nominations of single candidate
pairs.

Regards,

Christer



On 04/09/17 08:44, "Ice on behalf of Christer Holmberg"
<[e-mail] on behalf of [e-mail]> wrote:

>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
>
>_______________________________________________
>Ice mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ice