Subject: Re: [Ice] Issues related to ICE role switching and conflicts

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Jun 2016 07:50:12 +0000

Hi,

If I understand correctly, forking can only trigger a role change when the offerer is ICE lite, and the remote peers are full and lite.

Because, if the offerer is full ICE, it MUST take the controlling role, no matter if the remote peers are full or lite.

Regards,

Christer

From: Taylor Brandstetter <[email-masked]<mailto:[email-masked]>>
Date: Friday 27 May 2016 at 22:24
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] Issues related to ICE role switching and conflicts

Yes, sequential forking is the main use case. Specifically, it seems that the ability to switch ICE roles was intended for the third-party call control use cases described here: https://tools.ietf.org/html/rfc3725

On Fri, May 27, 2016 at 8:09 AM, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:
Sequential forking, I believe.

On Fri, May 27, 2016 at 5:57 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

What use-cases are there for a full->lite switch? When an endpoint realises that it’s no longer behind a NAT, and doesn’t want to use full ICE?

As far as I understand, ICE-lite is meant for “static” network boxes (gateways etc) that are not located behind a NAT.

Regards,

Christer

From: Ice <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday 26 May 2016 at 22:56
To: Taylor Brandstetter <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] Issues related to ICE role switching and conflicts

On Fri, May 20, 2016 at 9:16 AM, Taylor Brandstetter <[email-masked]<mailto:[email-masked]>> wrote:
While investigating a WebRTC issue related to ICE role conflicts, I noticed what seem to be some minor oddities with the rules surrounding ICE role determination. I'd like to hear what people think about these issues, and find out if I'm overlooking any motivations for the current rules.

  1.  Section 5.1.2, Determining Role states "An ICE restart causes a new selection of roles and tiebreakers". The only time this is necessary, as far as I can tell, is when an agent is changing its implementation level (such as "full -> lite") and one agent needs to take up the controlling role. So it would be ideal if this was the only situation that caused new role selection. Otherwise, in a third-party call control use case that resulted in a role conflict initially, every ICE restart will probably result in another role conflict, as the agents re-select their initial conflicting roles. Also, what happens if ICE is restarting for only one media stream and the role changes according to this rule? From the perspective of the non-restarting media streams, the role would be switching in the middle of ICE processing.

​I think that the two rules in the spec of "must change role" and "role must be the same for all media streams" is bad combination, and I assume a mistake in RFC5245 that no one noticed before.  Changing the role of the non-restarted media streams is unnecessary and can only lead to problems.   But rather than have to have per-media-stream roles (relaxing the second rule), I think it would be easier to not change the role with an ICE restart (in other words, relax the first rule).  As you point out, there really isn't any reason to except if the remote side moves from full to lite, which can be handled with a specific rule rather than a general "must always change" rule.

So, I agree with changing the rule from "always change the role for all media streams when any stream is restarted" to "never change the role except when the remote implementation level switches to a lite implementation".​

  1.  Also, why select a new tiebreaker? I don't see any real issue with this, but it seems pointless.

I also don't see a point, and would be in favor of not requiring it to change, if we can't think of a good reason to require it to change.

  1.  There's nothing that says "when changing implementation level, you MUST restart ICE for all media streams". This requirement existed in draft 13 of ICE, but then there was a bunch of restructuring and I think it may have been removed accidentally. Regardless, I believe this condition should be added back, because changing implementation level in the middle of ICE processing for a media stream doesn't make much sense.

If the implementation level must be the same for all media streams (and it must be, right?), then I think you're right that we should require an ICE restart for all the media streams when the implementation level changes.  Otherwise, as you say, a given media stream will have the remote implementation level change without a restart, which seems problematic.  And I don't see any reason why you wouldn't restart all media streams when you change the implementation level (presumably you're talking to a different endpoint anyway).

  1.  Section 6.1.3.1, Failure Cases states that when receiving a "role conflict" error response, "the agent MUST switch to the (controlling|controlled) role if it has not already done so". The condition "if it has not already done so", if interpreted literally, means that the agent can only switch to a role once. I don't think this was the intention, so the condition can probably be removed. It's worth noting that this condition doesn't exist in Section 6.2.1.1, Detecting and Repairing Role Conflicts.

​I agree that it should be more clear, and would be with your suggested text change.
​

  1.  Starting to really stretch here, but in the rare situation where there's a role conflict and the tie-breakers are equal, the peers could continue flipping between roles ad infinitum. Why not just generate a new tie-breaker? I saw that this was once brought up on the MMUSIC mailing list but I couldn't find a response.

​It seems so rare as to not matter.  But if it would make you and others feel more comfortable, I'd be fine with that logic.​

If there's general agreement about these points, I'll happily write some pull requests for ICEbis.

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

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

---

From: Taylor Brandstetter <[email-masked]>
Date: Thu, 16 Jun 2016 09:28:22 -0700

If I understand correctly, your point is that changing from "full -> full"
to "full -> lite" would not require a role change, because the offering
endpoint would already have the "controlling" role?

However, there are still situations where the "full" peer could end up with
a "controlled" role, such as:

   1. The full peer being transferred to the lite peer was the answerer
   initially.
   2. Both endpoints in the initial offer/answer exchange believed
   themselves to be the offerer (or answerer), leaving the initial role
   decision up to the tie-breaker.
   3. The offer->answer direction is reversed in the second exchange.

On Thu, Jun 16, 2016 at 12:50 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> If I understand correctly, forking can only trigger a role change when the
> offerer is ICE lite, and the remote peers are full and lite.
>
> Because, if the offerer is full ICE, it MUST take the controlling role, no
> matter if the remote peers are full or lite.
>
> Regards,
>
> Christer
>
>
> From: Taylor Brandstetter <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: Christer Holmberg <[email-masked]>, "[email-masked]" <
> [email-masked]>
>
> Yes, sequential forking is the main use case. Specifically, it seems that
> the ability to switch ICE roles was intended for the third-party call
> control use cases described here: https://tools.ietf.org/html/rfc3725
>
> On Fri, May 27, 2016 at 8:09 AM, Peter Thatcher <[email-masked]>
> wrote:
>
>> On Fri, May 27, 2016 at 5:57 AM, Christer Holmberg <
>> [email-masked]> wrote:
>>
>>>
>>> Hi,
>>>
>>> What use-cases are there for a full->lite switch? When an endpoint
>>> realises that it’s no longer behind a NAT, and doesn’t want to use full ICE?
>>>
>>> As far as I understand, ICE-lite is meant for “static” network boxes
>>> (gateways etc) that are not located behind a NAT.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>> From: Ice <[email-masked]> on behalf of "[email-masked]" <
>>> [email-masked]>
>>> To: Taylor Brandstetter <[email-masked]>
>>> Cc: "[email-masked]" <[email-masked]>
>>> On Fri, May 20, 2016 at 9:16 AM, Taylor Brandstetter <
>>> [email-masked]> wrote:
>>>
>>>> While investigating a WebRTC issue related to ICE role conflicts, I
>>>> noticed what seem to be some minor oddities with the rules surrounding ICE
>>>> role determination. I'd like to hear what people think about these issues,
>>>> and find out if I'm overlooking any motivations for the current rules.
>>>>
>>>>    1. Section 5.1.2, Determining Role states "An ICE restart causes a
>>>>    new selection of roles and tiebreakers". The only time this is necessary,
>>>>    as far as I can tell, is when an agent is changing its implementation level
>>>>    (such as "full -> lite") and one agent *needs* to take up the
>>>>    controlling role. So it would be ideal if this was the only situation that
>>>>    caused new role selection. Otherwise, in a third-party call control use
>>>>    case that resulted in a role conflict initially, *every* ICE
>>>>    restart will probably result in another role conflict, as the agents
>>>>    re-select their initial conflicting roles. Also, what happens if ICE is
>>>>    restarting for only one media stream and the role changes according to this
>>>>    rule? From the perspective of the non-restarting media streams, the role
>>>>    would be switching in the middle of ICE processing.
>>>>
>>>> ​I think that the two rules in the spec of "must change role" and "role
>>> must be the same for all media streams" is bad combination, and I assume a
>>> mistake in RFC5245 that no one noticed before.  Changing the role of the
>>> non-restarted media streams is unnecessary and can only lead to problems.
>>> But rather than have to have per-media-stream roles (relaxing the second
>>> rule), I think it would be easier to not change the role with an ICE
>>> restart (in other words, relax the first rule).  As you point out, there
>>> really isn't any reason to except if the remote side moves from full to
>>> lite, which can be handled with a specific rule rather than a general "must
>>> always change" rule.
>>>
>>> So, I agree with changing the rule from "always change the role for all
>>> media streams when any stream is restarted" to "never change the role
>>> except when the remote implementation level switches to a lite
>>> implementation".​
>>>
>>>
>>>>
>>>> I also don't see a point, and would be in favor of not requiring it to
>>> change, if we can't think of a good reason to require it to change.
>>>
>>>
>>>>
>>>>    1. There's nothing that says "when changing implementation level,
>>>>    you MUST restart ICE for *all* media streams". This requirement
>>>>    existed in draft 13 of ICE, but then there was a bunch of restructuring and
>>>>    I think it may have been removed accidentally. Regardless, I believe this
>>>>    condition should be added back, because changing implementation level in
>>>>    the middle of ICE processing for a media stream doesn't make much sense.
>>>>
>>>> If the implementation level must be the same for all media streams (and
>>> it must be, right?), then I think you're right that we should require an
>>> ICE restart for all the media streams when the implementation level
>>> changes.  Otherwise, as you say, a given media stream will have the remote
>>> implementation level change without a restart, which seems problematic.
>>> And I don't see any reason why you wouldn't restart all media streams when
>>> you change the implementation level (presumably you're talking to a
>>> different endpoint anyway).
>>>
>>>
>>>>
>>>>    1. Section 6.1.3.1, Failure Cases states that when receiving a
>>>>    "role conflict" error response, "the agent MUST switch to the
>>>>    (controlling|controlled) role if it has not already done so". The condition
>>>>    "if it has not already done so", if interpreted literally, means that the
>>>>    agent can only switch to a role once. I don't think this was the intention,
>>>>    so the condition can probably be removed. It's worth noting that this
>>>>    condition doesn't exist in Section 6.2.1.1, Detecting and Repairing Role
>>>>    Conflicts.
>>>>
>>>>    1. Starting to really stretch here, but in the rare situation where
>>>>    there's a role conflict and the tie-breakers are equal, the peers could
>>>>    continue flipping between roles ad infinitum. Why not just generate a new
>>>>    tie-breaker? I saw that this was once brought up on the MMUSIC mailing list
>>>>    but I couldn't find a response.
>>>>
>>>> ​It seems so rare as to not matter.  But if it would make you and
>>> others feel more comfortable, I'd be fine with that logic.​
>>>
>>>
>>>
>>>> [email-masked]
>>> [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Jun 2016 16:38:27 +0000

Hi,

>If I understand correctly, your point is that changing from "full -> full" to "full -> lite" would not require a role 
>change, because the offering endpoint would already have the "controlling" role?

Correct. Note, though, that my comment was only on the initial offer, when forking can occur.

>However, there are still situations where the "full" peer could end up with a "controlled" role, such as:
>
>1. The full peer being transferred to the lite peer was the answerer initially.

Correct.

>2. Both endpoints in the initial offer/answer exchange believed themselves to be the offerer (or answerer), leaving the initial role decision up to the tie-breaker.

I am not sure how that would occur: an endpoint always know whether it's an offerer or answerer.

>3. The offer->answer direction is reversed in the second exchange.

Correct.

So, we need to work on text which says that, once the roles have been determined, endpoints should not change them during an ICE restart - unless they have to.

In offer/answer terminology that means that, when a subsequent offer is sent - for whatever reason (including, but not limited to, an ICE restart) - the roles should not change.

In 5245bis we don't talk about offers and answers, so we have to write similar text using more generic language.

Regards,

Christer

On Thu, Jun 16, 2016 at 12:50 AM, Christer Holmberg <[email-masked]> wrote:
Hi,

Regards,

Christer

From: Taylor Brandstetter <[email-masked]>
Date: Friday 27 May 2016 at 22:24
To: "[email-masked]" <[email-masked]>
Cc: Christer Holmberg <[email-masked]>, "[email-masked]" <[email-masked]>

On Fri, May 27, 2016 at 8:09 AM, Peter Thatcher <[email-masked]> wrote:
Sequential forking, I believe.

On Fri, May 27, 2016 at 5:57 AM, Christer Holmberg <[email-masked]> wrote:

Hi,

Regards,

Christer

From: Ice <[email-masked]> on behalf of "[email-masked]" <[email-masked]>

On Fri, May 20, 2016 at 9:16 AM, Taylor Brandstetter <[email-masked]> wrote:
While investigating a WebRTC issue related to ICE role conflicts, I noticed what seem to be some minor oddities with the rules surrounding ICE role determination. I'd like to hear what people think about these issues, and find out if I'm overlooking any motivations for the current rules. 
1. Section 5.1.2, Determining Role states "An ICE restart causes a new selection of roles and tiebreakers". The only time this is necessary, as far as I can tell, is when an agent is changing its implementation level (such as "full -> lite") and one agent needs to take up the controlling role. So it would be ideal if this was the only situation that caused new role selection. Otherwise, in a third-party call control use case that resulted in a role conflict initially, every ICE restart will probably result in another role conflict, as the agents re-select their initial conflicting roles. Also, what happens if ICE is restarting for only one media stream and the role changes according to this rule? From the perspective of the non-restarting media streams, the role would be switching in the middle of ICE processing.
​I think that the two rules in the spec of "must change role" and "role must be the same for all media streams" is bad combination, and I assume a mistake in RFC5245 that no one noticed before.  Changing the role of the non-restarted media streams is unnecessary and can only lead to problems.   But rather than have to have per-media-stream roles (relaxing the second rule), I think it would be easier to not change the role with an ICE restart (in other words, relax the first rule).  As you point out, there really isn't any reason to except if the remote side moves from full to lite, which can be handled with a specific rule rather than a general "must always change" rule.

---

From: Taylor Brandstetter <[email-masked]>
Date: Thu, 16 Jun 2016 10:38:48 -0700

> I am not sure how that would occur: an endpoint always know whether it's
an offerer or answerer.

If an endpoint always knows whether it's an offerer or an answerer, there
would be no point in having a tie-breaker.

One example of how this is possible:
https://tools.ietf.org/html/rfc3725#section-4.2
In short, the third-party call control system acts as the offerer for each
of the endpoints it's connecting.

This was apparently brought up at IETF 68. See slide 15:
https://www.ietf.org/proceedings/68/slides/mmusic-0.pdf

> So, we need to work on text which says that, once the roles have been
determined, endpoints should not change them during an ICE restart - unless
they have to.

Agreed.

On Thu, Jun 16, 2016 at 9:38 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> >If I understand correctly, your point is that changing from "full ->
> full" to "full -> lite" would not require a role
> So, we need to work on text which says that, once the roles have been
> determined, endpoints should not change them during an ICE restart - unless
> they have to.
>
> In offer/answer terminology that means that, when a subsequent offer is
> sent - for whatever reason (including, but not limited to, an ICE restart)
> - the roles should not change.
>
> In 5245bis we don't talk about offers and answers, so we have to write
> similar text using more generic language.
>
> Regards,
>
> Christer
>
>
>
> 1. Section 5.1.2, Determining Role states "An ICE restart causes a new
> selection of roles and tiebreakers". The only time this is necessary, as
> far as I can tell, is when an agent is changing its implementation level
> (such as "full -> lite") and one agent needs to take up the controlling
> role. So it would be ideal if this was the only situation that caused new
> role selection. Otherwise, in a third-party call control use case that
> resulted in a role conflict initially, every ICE restart will probably
> result in another role conflict, as the agents re-select their initial
> conflicting roles. Also, what happens if ICE is restarting for only one
> media stream and the role changes according to this rule? From the
> perspective of the non-restarting media streams, the role would be
> switching in the middle of ICE processing.
> 1. There's nothing that says "when changing implementation level, you MUST
> restart ICE for all media streams". This requirement existed in draft 13 of
> ICE, but then there was a bunch of restructuring and I think it may have
> been removed accidentally. Regardless, I believe this condition should be
> added back, because changing implementation level in the middle of ICE
> processing for a media stream doesn't make much sense.
> If the implementation level must be the same for all media streams (and it
> must be, right?), then I think you're right that we should require an ICE
> restart for all the media streams when the implementation level changes.
> Otherwise, as you say, a given media stream will have the remote
> 1. Section 6.1.3.1, Failure Cases states that when receiving a "role
> conflict" error response, "the agent MUST switch to the
> ​It seems so rare as to not matter.  But if it would make you and others
> feel more comfortable, I'd be fine with that logic.​
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Jun 2016 17:52:18 +0000

Hi,

> If an endpoint always knows whether it's an offerer or an answerer, there would be no point in having a tie-breaker.
>
> One example of how this is possible: https://tools.ietf.org/html/rfc3725#section-4.2
> In short, the third-party call control system acts as the offerer for each of the endpoints it's connecting.
>
> This was apparently brought up at IETF 68. See slide 15: https://www.ietf.org/proceedings/68/slides/mmusic-0.pdf

People talk about these 3pcc cases, but it would be really nice to see an example :)

However, I don't think the issue is that the endpoints don’t know whether they are an offerer or and answerer - I think they case is that they both act as offerer.

Example:

- A establishes a session with B. A is the controller.

- C (3pcc controller) sends an offer to A, in order to transfer A to D.

- C takes the role as controller. A is the controller from the initial negotiation with B. 

- Now, it needs to be decided whether A or C is controller. I guess the tie-breaker could be used to determine that - but A could also simply send an answer and change its role to CONTROLLED.

But,  again, I have no idea whether this is the 3pcc case people have had in mind :)

Since we define the tie-breaker, I really think we should have an example where it's needed, instead of only saying "in certain 3pcc cases".

Regards,

Christer

On Thu, Jun 16, 2016 at 9:38 AM, Christer Holmberg <[email-masked]> wrote:
Hi,

Correct.

Correct.

Regards,

Christer

Regards,

Christer

Hi,

Regards,

Christer

---

From: Taylor Brandstetter <[email-masked]>
Date: Thu, 16 Jun 2016 11:33:20 -0700

> However, I don't think the issue is that the endpoints don’t know whether
they are an offerer or and answerer - I think they case is that they both
act as offerer.

Yes, sorry if my wording was poor. The case I'm talking about is when the
endpoints performing ICE both acted as offerer (or answerer). Or in
RFC5245bis terminology, both acted as the initiator or responder.

https://tools.ietf.org/html/rfc3725#section-4.2, which I linked earlier,
shows an example of this. The flow is, in essence:

1. Controller sends offer to Alice.
2. Alice sends an answer to Controller, taking controlled role.
3. Controller sends offer to Bob using information from Alice's answer.
4. Bob sends answer to Controller, taking controlled role.
5. Now Alice is performing ICE with Bob, and they both have the controlled
role. Hence the tie-breaker is needed.

On Thu, Jun 16, 2016 at 10:52 AM, Christer Holmberg <
[email-masked]> wrote:

> > If an endpoint always knows whether it's an offerer or an answerer,
> there would be no point in having a tie-breaker.
> >
> However, I don't think the issue is that the endpoints don’t know whether
> they are an offerer or and answerer - I think they case is that they both
> act as offerer.
>
> Example:
>
> - Now, it needs to be decided whether A or C is controller. I guess the
> tie-breaker could be used to determine that - but A could also simply send
> an answer and change its role to CONTROLLED.
>
> Since we define the tie-breaker, I really think we should have an example
> where it's needed, instead of only saying "in certain 3pcc cases".
>
> Regards,
>
> Christer
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Jun 2016 19:02:59 +0000

Hi,

> Yes, sorry if my wording was poor. The case I'm talking about is when the endpoints performing ICE both acted as offerer (or answerer). Or
> in RFC5245bis terminology, both acted as the > initiator or responder.
>
> https://tools.ietf.org/html/rfc3725#section-4.2, which I linked earlier, shows an example of this. The flow is, in essence:
>
>5. Now Alice is performing ICE with Bob, and they both have the controlled role. Hence the tie-breaker is needed.

In step 3, Controller could take the controlled role in the offer to Bob. Then Bob is would take the controller role (unless he is ICE lite), and there would be no need for the tie-breaker.

Obviously, this would require a change in the current rules, saying that one must indicate Controller in the initial offer.

Regards,

Christer

On Thu, Jun 16, 2016 at 10:52 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Example:

Regards,

Christer

On Thu, Jun 16, 2016 at 9:38 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Correct.

Correct.

Regards,

Christer

On Thu, Jun 16, 2016 at 12:50 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Hi,

Regards,

Christer