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

From: Christer Holmberg <[email-masked]>
Date: Sat, 2 Sep 2017 08:00:06 +0000

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

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 3 Sep 2017 21:38:54 -0400

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 <
[email-masked]> wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Sep 2017 05:44:25 +0000

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"? 
>
>3. "I have selected a set of validated pairs for sending and will request consent for them"
>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 <[email-masked]> wrote:
Hi

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 5 Sep 2017 06:26:26 +0000

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"
<[email-masked] on behalf of [email-masked]> 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? :)"
>>
>>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.
>>
>>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?
>
>>flexibility for implementations to support mujlti-path RTP? (e.g.
>>sending different RTP flows using >different candidate pairs). Again,
>>not said explicitly anywhere.
>
>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.
>>
>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.
>
>>nomination and basing it on consent instead,
>
>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"? 
>>
>>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.
>
>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
>
>
>
>
>_______________________________________________
>Ice mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ice

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 5 Sep 2017 08:04:02 -0400

> question is whether we should allow re-nominations of single candidate

[BA] Actually, I was just trying to understand what the current draft allows and why. As it stands, the draft appears to support multi-path RTP before nomination, but not after.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 5 Sep 2017 12:26:33 +0000

Hi,

>[BA] Actually, I was just trying to understand what the current draft
>allows and why. As it stands, the draft appears to support multi-path RTP
>before nomination, but not after.

Currently, the draft allows switching between pairs before nomination,
yes. As for WHY, I assume it is to allow media transport before the ICE
procedures have finished.

Regards,

Christer

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 05 Sep 2017 23:48:53 +0000

Thinking about this some more: I think it's fine if 5245bis says that you
can't renominate.  We could say "an ICE option or extension may allow
renomination", but we could just put that in a new ICE option or extension
(like https://tools.ietf.org/html/draft-thatcher-ice-renomination-01).
Then it's clear that without the extension, you can't, but with the
extension you can.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 5 Sep 2017 18:52:02 -0600

On 9/5/17 5:48 PM, Peter Thatcher wrote:
> Thinking about this some more: I think it's fine if 5245bis says that
> you can't renominate.  We could say "an ICE option or extension may
> allow renomination", but we could just put that in a new ICE option or
> extension

+1

Peter

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 5 Sep 2017 17:54:49 -0700

> On Sep 5, 2017, at 16:48, Peter Thatcher <[email-masked]> wrote:
> 
> Thinking about this some more: I think it's fine if 5245bis says that you can't renominate.  We could say "an ICE option or extension may allow renomination", but we could just put that in a new ICE option or extension (like https://tools.ietf.org/html/draft-thatcher-ice-renomination-01 <https://tools.ietf.org/html/draft-thatcher-ice-renomination-01>).  Then it's clear that without the extension, you can't, but with the extension you can.

+1

  Nils Ohlmeier

> 
> 
> On Tue, Sep 5, 2017 at 5:26 AM Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
>