Subject: [Ice] 5245bis: tie-breaker issues

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

Hi,

I’ve found some issues regarding the tie-breaker value. I know the tie-breaker has been discussed in e-mails and/or meetings, so please let me know if the issues have been resolved. But, in any case, I think we the bis-draft needs some clarifications.

Q1:

The “tie-breaker”/“tie-breaker value” terminology is used throughout the document, but there is no clear “tie-breaker” definition.

Section 16.1, defining the new STUN attributes, does contain the following text:

   "The content of the attribute is a 64-bit unsigned integer in network byte order, which contains a random number used for tie-
   breaking of role conflicts.”

…but I think a more clear definition is needed. The following text exists in RFC 5245, but for some reason it has been removed from bis:

      “…, each agent MUST select a random number, called the tie-breaker, uniformly distributed between 0 and (2**64) - 1
      (that is, a 64-bit positive integer)."

Q2:

Section 6.1.2.3 says:

   “The content of either attribute MUST be the tie-breaker that was
   determined in Section 5.1.2.”

However, section 5.1.2 does not say anything about determining the tie-breaker. This is probably a left-over from RFC 5245.

Q3:

It is unclear whether a single tie-breaker value applies to the whole ICE session, i.e. all binding requests for all media.

There was an e-mail discussion related to this, back in 2012, where it was indicated that this will be clarified in bis:

https://www.ietf.org/mail-archive/web/mmusic/current/msg09708.html

I ASSUME we want to use the same value for the whole session, to make sure that an agent takes the same ICE role for all media in cases where the tie-breaker value is used to determine the role.

Regards,

Christer

---

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

I agree with your conclusion to Q3. Since each ICE agent uses a single ICE
role for the entire session, it only makes sense to use a single
tie-breaker value for the entire session as well. Of course, if the ICE
role were re-defined to be per-media-stream, the tie-breaker could be
per-media-stream as well.

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

> Hi,
>
> I’ve found some issues regarding the tie-breaker value. I know the
> tie-breaker has been discussed in e-mails and/or meetings, so please let me
> know if the issues have been resolved. But, in any case, I think we the
> bis-draft needs some clarifications.
>
>
> Q1:
>
> The “tie-breaker”/“tie-breaker value” terminology is used throughout the
> document, but there is no clear “tie-breaker” definition.
>
>    "The content of the attribute is a 64-bit unsigned integer in network
> byte order, which contains a random number used for tie-
> …but I think a more clear definition is needed. The following text exists
> in RFC 5245, but for some reason it has been removed from bis:
>
>       “…, each agent MUST select a random number, called the tie-breaker,
> uniformly distributed between 0 and (2**64) - 1
> However, section 5.1.2 does not say anything about determining the
> tie-breaker. This is probably a left-over from RFC 5245.
>
>
> Q3:
>
> It is unclear whether a single tie-breaker value applies to the whole ICE
> session, i.e. all binding requests for all media.
>
> There was an e-mail discussion related to this, back in 2012, where it was
> indicated that this will be clarified in bis:
>
> I ASSUME we want to use the same value for the whole session, to make sure
> that an agent takes the same ICE role for all media in cases where the
> tie-breaker value is used to determine the role.
>
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>
>

---

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

Hi,

>I agree with your conclusion to Q3. Since each ICE agent uses a single ICE role for the entire >session, it only makes sense to use a single tie-breaker value for the entire session as well. Of >course, if the ICE role were re-defined to be per-media-stream, the tie-breaker could be per->media-stream as well.

Sure. But, unless it’s already clear, we will clarify that the ICE role is also for the whole session (which is related to the discussion about ICE roles and restart).

Regards,

Christer

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

Q1:

Q2:

Section 6.1.2.3 says:

Q3:

Regards,

Christer

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Jun 2016 09:46:39 +0000

Hi,

What about the following test for the ICE-CONTROLLED and ICE-CONTROLLING definitions.

Note that, in addition to mandating that the same value must be used for all streams associated with the ICE session, the test also says MUST NOT change the value during the session – not even during an ICE restart. Are we ok with that, or do we want to be able to change the value?

Regards,

Christer

-----

<t>
The ICE-CONTROLLED attribute is present in a Binding request and
indicates that the client believes it is currently in the controlled
role. The content of the attribute is a 64-bit unsigned integer in
network byte order, which contains a random number. The number is used
for solving role conflicts, when it is referred to as the tie-breaker
value. An ICE agent MUST use the same number for all Bining requests,
for all streams, within an ICE session. The ICE agent MUST NOT change
the number when an ICE restart occurs, even if the ICE roles are
re-negotiated.
</t>

<t>
The ICE-CONTROLLING attribute is present in a Binding request and
indicates that the client believes it is currently in the controlling
role. The content of the attribute is a 64-bit unsigned integer in
network byte order, which contains a random number. The number is used
for solving role conflicts, when it is referred to as the tie-breaker
value. An ICE agent MUST use the same number for all Bining requests,
for all streams, within an ICE session. The ICE agent MUST NOT change
the number when an ICE restart occurs, even if the ICE roles are
re-negotiated.
</t>

-----

From: Ice <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Thursday 16 June 2016 at 20:22
To: Taylor Brandstetter <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] 5245bis: tie-breaker issues

Hi,

Regards,

Christer

Q1:

Q2:

Section 6.1.2.3 says:

Q3:

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Jun 2016 09:53:21 +0000

Hi,

Note, though, that the draft contains the following text:

  "Once roles are determined for a session, they persist unless ICE is
   restarted. An ICE restart causes a new selection of roles and
   tie-breakers.”

…which indicates that we DO allow new selection of tie-breaker values during an ICE restart. But, is there really a need to assign new values?

Regards,

Christer

From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Friday 17 June 2016 at 12:46
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, Taylor Brandstetter <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] 5245bis: tie-breaker issues

Hi,

Regards,

Christer

-----

<t>

<t>

-----

Hi,

Regards,

Christer

Q1:

Q2:

Section 6.1.2.3 says:

Q3:

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Jun 2016 10:39:05 +0000

Hi,

I’ve created a pull request with a suggestion how to clarify the tie-breaker.

Note that there is an open issue whether an ICE agent is allowed/required to change the tie-breaker value during an ICE restart, or during a tie-breaker role conflict. The current text seems to say that an ICE agent MUST choose new values in both cases.

https://github.com/ice-wg/rfc5245bis/pull/7

Regards,

Christer

Date: Friday 17 June 2016 at 12:53

Hi,

Regards,

Christer

Hi,

Regards,

Christer

-----

<t>

<t>

-----

Hi,

Regards,

Christer

Q1:

Q2:

Section 6.1.2.3 says:

Q3:

Regards,

Christer

---

From: Ari Keränen <[email-masked]>
Date: Fri, 17 Jun 2016 12:50:56 +0000

Hi,

I think we should align the non-broker functionality in bis as well as possible with 5245. Since 5245 says that ICE restart allows for tie-breaker change, we should not change that in bis.

For Q1, clarifying sound reasonable.

For Q3, same tie-breaker value for whole sessions seems right to me.

Cheers,
Ari

> On 17 Jun 2016, at 13:39, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> From: Christer Holmberg <[email-masked]>
> To: Christer Holmberg <[email-masked]>, Taylor Brandstetter <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> From: Christer Holmberg <[email-masked]>
> To: Christer Holmberg <[email-masked]>, Taylor Brandstetter <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> From: Ice <[email-masked]> on behalf of Christer Holmberg <[email-masked]>
> To: Taylor Brandstetter <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> On Thu, Jun 16, 2016 at 5:22 AM, Christer Holmberg <[email-masked]> wrote:
>> Hi,
>>

---

From: Ari Keränen <[email-masked]>
Date: Fri, 17 Jun 2016 12:52:20 +0000

> On 17 Jun 2016, at 15:52, Ari Keränen <[email-masked]> wrote:
> 
> I think we should align the non-broker functionality in bis as well as possible with 5245.

s/non-broker/non-broken/
(DYAC)

Cheers,
Ari

---

From: Taylor Brandstetter <[email-masked]>
Date: Fri, 17 Jun 2016 10:16:41 -0700

The "ICE restart must change tie-breaker" rule is something I also noticed
and brought up here
<https://www.ietf.org/mail-archive/web/ice/current/msg00208.html>.
It seems pointless, but it also doesn't do any harm. So I don't have any
objection to keeping it in.

Also, just an editorial comment: It may make more sense to define the
tie-breaker in its own section. Perhaps after "Determining ICE Role".

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 17 Jun 2016 10:37:38 -0700

If it doesn't matter whether or not an implementation does something (such
as changing the ICE breaker), then ​I'd suggest to just remove it from the
spec:  a shorter spec, and less to worry about.  If it must stay, then at
least make it a SHOULD instead of a MUST so implementations don't have to
do something pointless.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Jun 2016 20:21:14 +0000

Hi,

>If it doesn't matter whether or not an implementation does something (such as changing >the ICE breaker), then ​I'd suggest to just remove it from the spec:  a shorter spec, and >less to worry about.  If it must stay, then at least make it a SHOULD instead of a MUST >so implementations don't have to do something pointless.

If it stays, we should at least know why it’s a SHOULD/MUST. I did not find any explanation.

There is also text saying that a new value must be generated when a 487 has been received, but I didn’t find any justification for that either.

One way, unless we find a good use-case where a change of value is needed, could be to say that an endpoint must not change the value, but must be prepared that the peer may change its value.

Regards,

Christer

On Fri, Jun 17, 2016 at 10:16 AM, Taylor Brandstetter <[email-masked]<mailto:[email-masked]>> wrote:
The "ICE restart must change tie-breaker" rule is something I also noticed and brought up here<https://www.ietf.org/mail-archive/web/ice/current/msg00208.html>.
It seems pointless, but it also doesn't do any harm. So I don't have any objection to keeping it in.

Also, just an editorial comment: It may make more sense to define the tie-breaker in its own section. Perhaps after "Determining ICE Role".

On Fri, Jun 17, 2016 at 5:52 AM, Ari Keränen <[email-masked]<mailto:[email-masked]>> wrote:

> On 17 Jun 2016, at 15:52, Ari Keränen <[email-masked]<mailto:[email-masked]>> wrote:
>

s/non-broker/non-broken/
(DYAC)

Cheers,
Ari

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Jun 2016 20:25:18 +0000

…or, if we want to be less restrictive, we could say “MAY generate a new value”.

Regards,

Christer

From: Ice [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 17 June 2016 23:21
To: Peter Thatcher <[email-masked]>; Taylor Brandstetter <[email-masked]>
Cc: Ari Keränen <[email-masked]>; [email-masked]
Subject: Re: [Ice] 5245bis: tie-breaker issues

Hi,

Regards,

Christer

s/non-broker/non-broken/
(DYAC)

Cheers,
Ari

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Jun 2016 11:41:37 +0000

Hi,

I’ve updated the tie-breaker-clarification pull request. It now also contains text specifying that the roles must not be re-determined as part of an ICE restart – unless required by some of the criteria listed by Taylor.

https://github.com/ice-wg/rfc5245bis/tree/tie-breaker-clarification

I do intend to submit a new version of draft-5245bis relatively soon, and merge the pull request, so please take a look.

Regards,

Christer

From: Ice <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Friday 17 June 2016 at 23:25
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Taylor Brandstetter <[email-masked]<mailto:[email-masked]>>
Cc: Ari Keränen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] 5245bis: tie-breaker issues

Regards,

Christer

From: Ice [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 17 June 2016 23:21
To: Peter Thatcher <[email-masked]<mailto:[email-masked]>>; Taylor Brandstetter <[email-masked]<mailto:[email-masked]>>
Cc: Ari Keränen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ice] 5245bis: tie-breaker issues

Hi,

Regards,

Christer

s/non-broker/non-broken/
(DYAC)

Cheers,
Ari