Subject: [Ice] Pull request: Candidate nomination rejection

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Sep 2017 13:08:52 +0000

Hi,

I have created a PR, which adds procedure text (controlling agent) for when a nomination request is rejected, and procedure text (controlled agent) for rejecting a nomination.

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

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Mon, 11 Sep 2017 13:16:48 +0000

Could someone please remind what the larger goal is here?

Emil

On Mon, 11 Sep 2017 at 08:09, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> I have created a PR, which adds procedure text (controlling agent) for
> when a nomination request is rejected, and procedure text (controlled
> agent) for rejecting a nomination.
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>
-- 
sent from my mobile

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Sep 2017 13:21:17 +0000

Publication of the RFC.

From: Emil Ivov <[email-masked]<mailto:[email-masked]>>
Date: Monday 11 September 2017 at 16:16
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] Pull request: Candidate nomination rejection

Emil

On Mon, 11 Sep 2017 at 08:09, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Sep 2017 13:24:04 +0000

Seriously, these are two questions that have come up:

1) What if a nomination request fails?
2) How can the controlled agent explicitly reject a nomination?

The PR suggests answers to those questions.

Regards,

Christer

From: Ice <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Monday 11 September 2017 at 16:21
To: Emil Ivov <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] Pull request: Candidate nomination rejection

Publication of the RFC.

Emil

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Mon, 11 Sep 2017 09:23:27 -0500

Thanks Christer,

I did gather that much, but I was just wondering why we are talking
about rejecting nominations and then not saying why you would do it.

In other words, as a controlling agent what am I supposed to do with a
rejection? Without the current text I probably would have failed ICE
processing because I don't want to guess the reasons the controlled
had for doing it. The new text doesn't help me with this.

Emil

On Mon, Sep 11, 2017 at 8:24 AM, Christer Holmberg
<[email-masked]> wrote:
> From: Ice <[email-masked]> on behalf of Christer Holmberg
> <[email-masked]>
> To: Emil Ivov <[email-masked]>, "[email-masked]" <[email-masked]>
> From: Emil Ivov <[email-masked]>
> To: Christer Holmberg <[email-masked]>, "[email-masked]"
> <[email-masked]>
> On Mon, 11 Sep 2017 at 08:09, Christer Holmberg
> <[email-masked]> wrote:
>>
>> Hi,
>>
>> when a nomination request is rejected, and procedure text (controlled agent)
>> for rejecting a nomination.
>>

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Sep 2017 14:51:37 +0000

Hi,

>I did gather that much, but I was just wondering why we are talking about rejecting >nominations and then not saying why you would do it.

We did discuss whether one should be allowed to reject a nomination in the first place.

Perhaps the pair is using a very bad/expensive/slow connection.

>In other words, as a controlling agent what am I supposed to do with a rejection? Without >the current text I probably would have failed ICE processing because I don't want to guess >the reasons the controlled had for doing it. The new text doesn't help me with this.

The new text says that the controlling agent can choose another pair, or set the check list state to failed. The old text more or less assumed that the nomination would succeed.

Regards,

Christer

On Mon, Sep 11, 2017 at 8:24 AM, Christer Holmberg <[email-masked]> wrote:
>> I have created a PR, which adds procedure text (controlling agent) 
>> for when a nomination request is rejected, and procedure text 
>> (controlled agent) for rejecting a nomination.
>>

--
https://jitsi.org

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 11 Sep 2017 17:07:01 +0000

I think the goal of first part of the PR is good, where we specify/clarify
what to do when the nomination STUN transaction fails.

But I think there is a problem with the option of "nominate another pair":
 if the transaction fails because the request is delayed on the network
(such that the transaction times out) then the controlled side will see a
nomination, but the controlling side won't know that it did.  So the
controlling side will then nominate a different pair, and the controlling
side will see two nominations, possibly with the first arriving last, and
the two sides will be out of sync.

I think it might be better to just say the controlling side must set the
check list to the failed state.  It's probably a very rare situation
anyway, and if we think we need better, there's always an ICE extension
like renomination :).

As for the "controlled side can reject the nomination" part of the PR: if
we keep the "controlling side may nominate another pair" rule, but only if
the controlled side rejected it (not because of STUN transaction timeout),
then I could see the problem I pointed out above not being a problem any
more.  But I'm not sure we want to go down this path "controlling side
keeps nominating until the controlled side accepts" thing.  I think it
would be more simple to just say the controlled side MUST accept the
transaction or the check list goes to the failed state.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Sep 2017 19:46:50 +0000

Hi,

>I think the goal of first part of the PR is good, where we specify/clarify what to do when the nomination STUN transaction fails.
>
>But I think there is a problem with the option of "nominate another pair":  if the transaction fails because the request is delayed on the network (such that >the transaction times out) then the controlled side will see a nomination, but the controlling side won't know that it did.  So the controlling side will then >nominate a different pair, and the controlling side will see two nominations, possibly with the first arriving last, and the two sides will be out of sync.
>
>I think it might be better to just say the controlling side must set the check list to the failed state.  It's probably a very rare situation anyway, and if we think >we need better, there's always an ICE extension like renomination :).

We can do that.

>As for the "controlled side can reject the nomination" part of the PR: if we keep the "controlling side may nominate another pair" rule, but only if the >controlled side rejected it (not because of STUN transaction timeout), then I could see the problem I pointed out above not being a problem any more.  But >I'm not sure we want to go down this path "controlling side keeps nominating until the controlled side accepts" thing.  I think it would be more simple to >just say the controlled side MUST accept the transaction or the check list goes to the failed state.

I assume “goes to the failed state” includes rejecting the transaction?

Now, the text does say that the controlled side has to be prepared for multiple nominations, in case the controlling endpoint is legacy does aggressive nomination. The spec says that the controlled SHOULD select the nominated pair with the highest priority, but assuming the controlled endpoints accepts all nomination transactions there is no way for the controlled endpoint to indicate to the controlling endpoint which pair was finally selected... We COULD of course say that the controlled endpoint should reject any additional nomination transactions, but maybe that could cause trouble with legacy endpoints…?

Regards,

Christer

On Mon, Sep 11, 2017 at 6:09 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Mon, 11 Sep 2017 19:55:00 +0000

On Mon, 11 Sep 2017 at 12:07, Peter Thatcher <[email-masked]> wrote:

>
> I think it would be more simple to just say the controlled side MUST
> accept the transaction or the check list goes to the failed state.
>

Yes, I am much more in favor of that!

Emil

-- 
sent from my mobile

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Sep 2017 07:07:36 +0000

Pull request updated, based on Peter’s and Emil’s comments.

Regards,

Christer

From: Emil Ivov <[email-masked]<mailto:[email-masked]>>
Date: Monday 11 September 2017 at 22:55
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] Pull request: Candidate nomination rejection

On Mon, 11 Sep 2017 at 12:07, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:

I think it would be more simple to just say the controlled side MUST accept the transaction or the check list goes to the failed state.

Emil

Regards,

Christer

---

From: Ari Keränen <[email-masked]>
Date: Tue, 12 Sep 2017 14:45:10 +0000

Looks good to me. Although instead of saying "MUST reply with 400", I'd suggest selecting more appropriate error code if one is available. For example: "MUST reject the nomination request with appropriate error code response (e.g., 400)".

Cheers,
Ari

> On 12 Sep 2017, at 10.07, Christer Holmberg <[email-masked]> wrote:
> 
> To: Christer Holmberg <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>> On Mon, Sep 11, 2017 at 6:09 AM Christer Holmberg <[email-masked]> wrote:
>>> Hi,
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Sep 2017 06:49:52 +0000

Hi,

PR updated based on Ari¹s comment (also fixed the editorial nit you
mentioned on GitHub).

Regards,

Christer

On 12/09/17 17:45, "Ari Keränen" <[email-masked]> wrote:

>Looks good to me. Although instead of saying "MUST reply with 400", I'd
>suggest selecting more appropriate error code if one is available. For
>example: "MUST reject the nomination request with appropriate error code
>response (e.g., 400)".
>
>
>Cheers,
>Ari
>
>> Pull request updated, based on Peter¹s and Emil¹s comments.
>> 
>> Regards,
>> 
>> Christer
>> 
>> To: Christer Holmberg <[email-masked]>,
>>"[email-masked]" <[email-masked]>, "[email-masked]"
>><[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Sep 2017 12:50:17 +0000

Hi,

I intend to merge the PR tomorrow, and submit a new version of the draft.
If you have any issues, please raise those TODAY.

In addition, I will merge Jonathan L’s PR
(https://github.com/ice-wg/rfc5245bis/pull/43), and include it in the new
version.

(Peter’s PR will be merged into the following version after that.)

Regards,

Christer