Subject: [Ice] I updated PR 38 and I have a question about nomination/selection

From: Peter Thatcher <[email-masked]>
Date: Thu, 07 Sep 2017 00:41:21 +0000

I updated https://github.com/ice-wg/rfc5245bis/pull/38/files from all of
the comments at IETF 99.  I think I have everything resolved except for the
whole "when can you free a candidate" thing.    Take a look for more
details.

And my question is this:  Selection on the controlled side is only SHOULD
strength, meaning the controlled side can simply ignore nominations from
the controlling side.  Does that mean that controlled side can choose to
never select a candidate pair?  And if an agent never selects a candidate
pair, can it not always send on any valid candidate pair of its choosing?

In other words, if an agent chooses to ignore all nominations and never
select a candidate pair, but instead to send on candidate pairs without
selecting them and switch between candidate pairs as its sees fit, is that
agent still spec-compliant?

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Sep 2017 06:15:11 +0000

Hi,

If the controlled side, for whatever reason, doesn’t accept the nomination, it should reject the nomination request. In my opinion, once a pair has been selected, it must be used.

Regards,

Christer

From: Ice <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday 7 September 2017 at 03:41
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Ice] I updated PR 38 and I have a question about nomination/selection

I updated https://github.com/ice-wg/rfc5245bis/pull/38/files from all of the comments at IETF 99.  I think I have everything resolved except for the whole "when can you free a candidate" thing.    Take a look for more details.

And my question is this:  Selection on the controlled side is only SHOULD strength, meaning the controlled side can simply ignore nominations from the controlling side.  Does that mean that controlled side can choose to never select a candidate pair?  And if an agent never selects a candidate pair, can it not always send on any valid candidate pair of its choosing?

In other words, if an agent chooses to ignore all nominations and never select a candidate pair, but instead to send on candidate pairs without selecting them and switch between candidate pairs as its sees fit, is that agent still spec-compliant?

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 6 Sep 2017 23:19:57 -0700

Peter said:

"And my question is this:  Selection on the controlled side is only SHOULD
strength, meaning the controlled side can simply ignore nominations from
the controlling side. Does that mean that controlled side can choose to
never select a candidate pair?"

[BA] "Ignoring nominations" might mean several things:

a. Not being prepared to receive on the selected pair.
b. Retaining resources outside the selected pair
c. Choosing to send on a validated pair other than the selected pair
(presumably with consent)

I would suggest that b) and c) are acceptable behaviors, but that a) is
not.

 "And if an agent never selects a candidate pair, can it not always send on
any valid candidate pair of its choosing?"

[BA] Without nomination *either* controlled or controlling sides can send
on any valid candidate pair, and there is not even a requirement for
symmetry. It is even possible for either side to simultaneously send
streams on different valid candidate pairs  (e.g. multi-path RTP). Either
side can release resources by refusing consent on a candidate that they
would prefer not to receive with, or by no longer requesting consent for a
candidate they no longer wish to send with.

The downside is the potential for consent failures that RFC 7675 insists
results in pair invalidation. So if you don't want to keep a WWAN interface
up to save power, unless there is a way to explicitly "remove" and then
"add" it back, then candidates involving that interface will be released.
TURN mobility offers a way to quickly bring up media flow using an awakened
interface, but if all other pairs involving that interface have been
invalidated, then you're stuck with the relay candidate unless you do an
ICE restart.  Ugh.

"In other words, if an agent chooses to ignore all nominations and never
select a candidate pair, but instead to send on candidate pairs without
selecting them and switch between candidate pairs as its sees fit, is that
agent still spec-compliant?"

[BA] I think it's ok for the controlling side not to nominate a pair, but
if it does, then the controlled side needs to be prepared to receive on
that pair.

On Wed, Sep 6, 2017 at 5:41 PM, Peter Thatcher <[email-masked]> wrote:

> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Sep 2017 06:43:30 +0000

Hi,

>Peter said:
>
>"And my question is this:  Selection on the controlled side is only SHOULD strength, meaning the controlled side can simply ignore nominations from the controlling side. Does that mean that controlled side can choose to never select a candidate pair?"
>
>c. Choosing to send on a validated pair other than the selected pair (presumably with consent)
>
>I would suggest that b) and c) are acceptable behaviors, but that a) is not.

I don’t think we should allow c). We can of course not prevent implementations from doing so, but it should not be 5245bis-endorsed behaviour. We select a pair, and then we use it.

> "And if an agent never selects a candidate pair, can it not always send on any valid candidate pair of its choosing?"
>
>[BA] Without nomination *either* controlled or controlling sides can send on any valid candidate pair, and there is not even a requirement for symmetry. It is even possible for either side to simultaneously send streams on different valid candidate pairs  (e.g. multi-path RTP).

I am not sure whether the intent ever was to allow simultaneous streams.

If it’s needed, I think some ICE-considerations-for-multipath-RTP should enhance ICE, and define how multiple pairs can be used both before and after nomination (or specify that nomination is never done). As far as 5245bis is concerned, I think we should say that only one pair is used at any given time, and that the controlling endpoint MUST nominate within a “reasonable” time.

>Either side can release resources by refusing consent on a candidate that they would prefer not to receive with, or by no longer requesting consent for a candidate they no longer wish to send with.
>
>The downside is the potential for consent failures that RFC 7675 insists results in pair invalidation. So if you don't want to keep a WWAN interface up to save power, unless there is a way to explicitly "remove" and then "add" it back, then candidates involving that
>interface will be released. TURN mobility offers a way to quickly bring up media flow using an awakened interface, but if all other pairs involving that interface have been invalidated, then you're stuck with the relay candidate unless you do an ICE restart.  Ugh.

>"In other words, if an agent chooses to ignore all nominations and never select a candidate pair, but instead to send on candidate pairs without selecting them and switch between candidate pairs as its sees fit, is that agent still spec-compliant?"
>
>[BA] I think it's ok for the controlling side not to nominate a pair, but if it does, then the controlled side needs to be prepared to receive on that pair.

And if it isn’t, it shouldn’t reply to the nomination request. Now, THAT is not really covered in the spec – the assumption seems to be that, as the nominated pair is in the valid list, the nomination will always succeed.

Regards,

Christer

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 07 Sep 2017 06:52:37 +0000

The spec says nothing about accepting or rejecting a nomination.  You are
correct that once a pair is selected, the spec says, but the spec does not
say that the controlling side needs to either accept or reject a
nomination.  It can simply ignore it and still be compliant (according to
my reading of the document).

On Wed, Sep 6, 2017 at 11:15 PM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> If the controlled side, for whatever reason, doesn’t accept the
> nomination, it should reject the nomination request. In my opinion, once a
> pair has been selected, it must be used.
>
> Regards,
>
> Christer
>
> From: Ice <[email-masked]> on behalf of "[email-masked]" <
> [email-masked]>
> To: "[email-masked]" <[email-masked]>

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 07 Sep 2017 07:02:32 +0000

On Wed, Sep 6, 2017 at 11:20 PM Bernard Aboba <[email-masked]>
wrote:

> Peter said:
>
> "And my question is this:  Selection on the controlled side is only
> SHOULD strength, meaning the controlled side can simply ignore nominations
> from the controlling side. Does that mean that controlled side can choose
> to never select a candidate pair?"
>

Or

d.  Not selecting a candidate pair

But that implies b) and c) are possible.

>  "And if an agent never selects a candidate pair, can it not always send
> on any valid candidate pair of its choosing?"
>
> symmetry.

I'm not saying there is no nomination.  I'm saying the controlling side
nominates, but the controlled side doesn't select (the spect doesn't
require it to).

> It is even possible for either side to simultaneously send streams on
> different valid candidate pairs  (e.g. multi-path RTP). Either side can
> release resources by refusing consent on a candidate that they would prefer
> not to receive with, or by no longer requesting consent for a candidate
> they no longer wish to send with.
>

> if it does, then the controlled side needs to be prepared to receive on
The spec says that an agent can't release candidates until it goes to the
Completed state (per check list), so I think it wouldn't be allowed to
release candidates until it selects, which means that if it doesn't select,
it must be able to receive on that pair (and, well, all pairs).

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 07 Sep 2017 07:07:28 +0000

On Wed, Sep 6, 2017 at 11:43 PM Christer Holmberg <
[email-masked]> wrote:

> I don’t think we should allow c). We can of course not prevent
> implementations from doing so, but it should not be 5245bis-endorsed
> behaviour. We select a pair, and then we use it.
>

The spec as currently written only says that the controlled side SHOULD
select.  It doesn't say it MUST.    So I believe C is allowed, as currently
written.

> streams on different valid candidate pairs  (e.g. multi-path RTP).
>
> If it’s needed, I think some ICE-considerations-for-multipath-RTP should
> enhance ICE, and define how multiple pairs can be used both before and
> after nomination (or specify that nomination is never done). As far as
> 5245bis is concerned, I think we should say that only one pair is used at
> any given time, and that the controlling endpoint MUST nominate within a
> “reasonable” time.
>

I'm not talking about nomination.  I'm talking about the controlled side
selecting or not (which is currently SHOULD strength).

But you're right that as currently written, the controlling side could also
choose not to select.   I don't know how you'd define a "reasonable" time.
What if ICE candidates keep trickling in with trickle ICE?

>
> >Either side can release resources by refusing consent on a candidate
> that they would prefer not to receive with, or by no longer requesting
> consent for a candidate they no longer wish to send with.
> >
> "add" it back, then candidates involving that
> >interface will be released. TURN mobility offers a way to quickly bring
> up media flow using an awakened interface, but if all other pairs involving
> that interface have been invalidated, then you're stuck with the relay
> candidate unless you do an ICE restart.  Ugh.
>
> And if it isn’t, it shouldn’t reply to the nomination request. Now, THAT
> is not really covered in the spec –
>

That's exactly my point.  The spec does not outline any way for the
controlling side to know that the controlled side honored its nomination or
not by selecting.

> the assumption seems to be that, as the nominated pair is in the valid
> list, the nomination will always succeed.
>

But the spec says that the controlled side SHOULD honor the nomination,
which means it might not!  So that assumption is not correct (with the
currently written text).

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Sep 2017 07:48:58 +0000

Hi,

The spec as currently written only says that the controlled side SHOULD select.  It doesn't say it MUST.    So I believe C is allowed, as currently written.

The spec might currently be unclear.

For example, section 2.6 says:

"Once the STUN transaction with the flag completes, both sides cancel any future checks for that media stream.
ICE will now send media using this pair. The pair an ICE agent is using for media is called the SELECTED PAIR."

To me that sounds like both endpoints will use the nominated pair.

I'm not talking about nomination.  I'm talking about the controlled side selecting or not (which is currently SHOULD strength).

I am not sure what you mean by “the controlled side selecting”. The selection is done by the controlling side, when nominating.

That is also written in the definition of “controlled agent”:

      "Controlled Agent:  An ICE agent that waits for the controlling agent
      to select the final choice of candidate pairs."

I assume you are talking about the controlled side not “accepting” the selection. But, as I said earlier, I don’t think the scenario is covered in the 5245bis. The text seems to assume that the selection done by the controlling endpoint will always succeed.

I have to admit that, since the removal of aggressive nomination, I fail to see the difference between “nomination” and “selection”. Since you are only going to nominate once, it’s basically the same thing, isn’t it?

But you're right that as currently written, the controlling side could also choose not to select.  I don't know how you'd define a "reasonable" time.  What if ICE candidates keep trickling in with trickle ICE?

>[BA] I think it's ok for the controlling side not to nominate a pair, but if it does, then the controlled side needs to be prepared to receive on that pair.

And if it isn’t, it shouldn’t reply to the nomination request. Now, THAT is not really covered in the spec –

That's exactly my point.  The spec does not outline any way for the controlling side to know that the controlled side honored its nomination or not by selecting.

If the controlling endpoint does not receive a reply to the STUN request with the nomination flag set, it should assume that the controlled endpoint did not honour the nomination. But, again, I don’t think the spec says anything about that. In fact, the text in section 7.1.1 seems to assume that nomination will always work:

   "Once the controlling agent has selected a valid pair for nomination,
   it repeats the connectivity check that produced this valid pair (by
   enqueueing the pair that generated the check into the TRIGGERED CHECK
   QUEUE), this time with the USE-CANDIDATE attribute.  The connectivity
   check should succeed (since the previous did), causing the nominated
   flag value of that and only that pair to be set to true."

the assumption seems to be that, as the nominated pair is in the valid list, the nomination will always succeed.

But the spec says that the controlled side SHOULD honor the nomination, which means it might not!  So that assumption is not correct (with the currently written text).

I think we need to forbid that – either by saying that the controlled endpoint MUST honour the nomination, OR by defining how the controlled endpoint can explicitly indicate that it didn’t honour.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Sep 2017 07:50:35 +0000

Hi,

…

In fact, the spec currently DOES forbid simultaneous steams:

      Selected Pair, Selected Candidate:  The candidate pair selected by
      ICE for sending and receiving media is called the selected pair,
      and each of its candidates is called the selected candidate.
      Before a pair has been selected, any valid candidate pair can be
      used for sending and receiving media (only one candidate pair at
      any given time).

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Sep 2017 07:52:46 +0000

Hi,

>The spec says nothing about accepting or rejecting a nomination.  You are correct that once a pair is selected, the spec says, but the spec does not say that the controlling side needs to either accept or reject a nomination.  It can simply ignore it and still be compliant (according to my reading of the document).

IF we allow it to ignore it, I think the controlling endpoint needs to be informed about it.

Regards,

Christer

On Wed, Sep 6, 2017 at 11:15 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 07 Sep 2017 15:30:24 +0000

On Thu, Sep 7, 2017 at 12:49 AM Christer Holmberg <
[email-masked]> wrote:

>> from the controlling side. Does that mean that controlled side can
>> choose to never select a candidate pair?"
>> >

Ah, you found it!  I was looking for something like that and couldn't find
it.  That implies that a check response of a (non-aggressive) nomination
implies that the controlled side has selected.  OK, so that's a good answer
to it.

Except is that a MUST-level or a SHOULD-level behavior?  Because elsewhere
in the doc it's a SHOULD-level.  So if it's MUST-level, there's a
contradiction.

>> >[BA] Without nomination *either* controlled or controlling sides can
>> send on any valid candidate pair, and there is not even a requirement for
> I am not sure what you mean by “the controlled side selecting”. The
> selection is done by the controlling side, when nominating.
>

But elsewhere in the document, it says "The controlled agent SHOULD select
the candidate pair", which means that the controlled side also selects.
There are two selections.  The flow is like this:

1.  Controlling selects
2.  Controlling nominates  (although maybe #1 and #2 should be flipped?)
3.  Controlled selects

> I assume you are talking about the controlled side not “accepting” the
> selection. But, as I said earlier, I don’t think the scenario is covered in
> the 5245bis. The text seems to assume that the selection done by the
> controlling endpoint will always succeed.
>

That's my point: we have a SHOULD-level phrase for something that we expect
to have happen.  But if it's SHOULD-level, what happens if it doesn't
happen.

>
> I have to admit that, since the removal of aggressive nomination, I fail
> to see the difference between “nomination” and “selection”. Since you are
> only going to nominate once, it’s basically the same thing, isn’t it?
>
>
Nomination means "you SHOULD select this", so it's not the same.

>
> But you're right that as currently written, the controlling side could
> also choose not to select.  I don't know how you'd define a "reasonable"
> time.  What if ICE candidates keep trickling in with trickle ICE?
>
>
>>
>> >[BA] I think it's ok for the controlling side not to nominate a pair,
>> but if it does, then the controlled side needs to be prepared to receive on
>> that pair.
>>
> If the controlling endpoint does not receive a reply to the STUN request
> with the nomination flag set, it should assume that the controlled endpoint
> did not honour the nomination. But, again, I don’t think the spec says
> anything about that. In fact, the text in section 7.1.1 seems to assume
> that nomination will always work:
>
> I think we need to forbid that – either by saying that the controlled
> endpoint MUST honour the nomination, OR by defining how the controlled
> endpoint can explicitly indicate that it didn’t honour.
>

I agree.  We should either make it MUST-level or we should define what
happens if the controlled side doesn't select.

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 07 Sep 2017 15:35:35 +0000

And a similar issue not covered: if the STUN transaction with the
nomination flag doesn't succeed (say the network goes out for a while).
Then what?  I think it means we're in a "half-selected" state (the
controlling side has selected but not the controlled side).  Is that OK?

On Thu, Sep 7, 2017 at 8:30 AM Peter Thatcher <[email-masked]> wrote:

>>> > "And if an agent never selects a candidate pair, can it not always
>>> send on any valid candidate pair of its choosing?"
>>> >
> That's my point: we have a SHOULD-level phrase for something that we
> expect to have happen.  But if it's SHOULD-level, what happens if it
> doesn't happen.
>
>
>>
>>> >The downside is the potential for consent failures that RFC 7675
>>> insists results in pair invalidation. So if you don't want to keep a WWAN
>>> interface up to save power, unless there is a way to explicitly "remove"
>>> and then "add" it back, then candidates involving that
>>> >interface will be released. TURN mobility offers a way to quickly
>>> bring up media flow using an awakened interface, but if all other pairs
>>> involving that interface have been invalidated, then you're stuck with the
>>> relay candidate unless you do an ICE restart.  Ugh.
>>>
>>> >"In other words, if an agent chooses to ignore all nominations and
>>> never select a candidate pair, but instead to send on candidate pairs
>>> without selecting them and switch between candidate pairs as its sees fit,
>>> is that agent still spec-compliant?"
>>> >

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 8 Sep 2017 07:50:04 +0000

Hi,

>And a similar issue not covered: if the STUN transaction with the nomination flag doesn't succeed (say the network goes out for a while).  Then what?  I think it means we're in a "half-selected" state (the controlling side has selected but not the controlled side).  Is that OK?

In my opinion the selection has completed once the STUN transaction has succeeded. Before that, we’re in the pre-selection state, where one can send media on all candidates etc. We should make that more clear in the spec. Then, if it happens, the controlling endpoint can choose what to do, e.g., try to nominate another pair in the valid list, or release the whole session. The exact action should be an implementation issue, in my opinion.

Regards,

Christer

On Thu, Sep 7, 2017 at 8:30 AM Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Sep 7, 2017 at 12:49 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Ah, you found it!  I was looking for something like that and couldn't find it.  That implies that a check response of a (non-aggressive) nomination implies that the controlled side has selected.  OK, so that's a good answer to it.

Except is that a MUST-level or a SHOULD-level behavior?  Because elsewhere in the doc it's a SHOULD-level.  So if it's MUST-level, there's a contradiction.

But elsewhere in the document, it says "The controlled agent SHOULD select the candidate pair", which means that the controlled side also selects.  There are two selections.  The flow is like this:

1.  Controlling selects

That's my point: we have a SHOULD-level phrase for something that we expect to have happen.  But if it's SHOULD-level, what happens if it doesn't happen.

I agree.  We should either make it MUST-level or we should define what happens if the controlled side doesn't select.

Regards,

Christer