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

From: Taylor Brandstetter <[email-masked]>
Date: Fri, 20 May 2016 09:16:57 -0700

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.
   2. Also, why select a new tiebreaker? I don't see any real issue with
   this, but it seems pointless.
   3. 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.
   4. 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.
   5. 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.

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

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 26 May 2016 12:56:43 -0700

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 May 2016 12:57:46 +0000

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

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 27 May 2016 08:09:08 -0700

Sequential forking, I believe.

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

---

From: Taylor Brandstetter <[email-masked]>
Date: Fri, 27 May 2016 12:24:38 -0700

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 20, 2016 at 9:16 AM, Taylor Brandstetter <[email-masked]
>> > wrote:
>>
>>>    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.
>>>