Subject: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis

From: Emil Ivov <[email-masked]>
Date: Mon, 21 Jul 2014 16:45:56 -0400

Hey all,

In London we mentioned the option of adding a new attribute that, during 
aggressive nomination, the controlling agent can use to notify its peer 
that ICE processing is over and no more changes are going to be 
attempted. This way controlled agents will no they can now release 
resources.

This could either be a new attribute (e.g., USE-CANDIDATE-CONFIRMED) or, 
as Justin suggested in an off-list discussion, we could have the 
controlling agent send a second USE-CANDIDATE once aggressive nomination 
converges.

Any thoughts?

Emil

-- 
https://jitsi.org

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 22 Jul 2014 09:57:44 +0000

> attempted. This way controlled agents will no they can now release 
+1

And it makes life somewhat easier for people looking through Wireshark traces trying to figure out why the ICE negotiation failed.

Middle boxes that understand ICE would also benefit from this. (As a side effect, not the main motivation)

> This could either be a new attribute (e.g., USE-CANDIDATE-CONFIRMED) or, 

I prefer this approach. The new attribute will not hurt backwards compatibility, and it is a nice hint to say that this behaviour is supported.

> controlling agent send a second USE-CANDIDATE once aggressive nomination 

I just want to avoid keeping more states in the ICE machinery. 

Keeping track of how many USE-CANIDATES received with the same USERNAME, but different STUN transaction Ids on the same 5-tuple is just a bit inconvenient. 

Or am I missing something?

.-.
Pål-Erik
 
> 
> Any thoughts?
> 
> Emil
> 
> 
> -- 
> https://jitsi.org
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Ari Keränen <[email-masked]>
Date: Tue, 22 Jul 2014 11:02:34 -0400

Hi,

> controlling agent send a second USE-CANDIDATE once aggressive nomination

Did you consider using the updated offer to indicate that you're really 
done? This would require that you always send it (i.e., a slight 
modification to 5245), but that's something that has been already 
proposed to be updated for other purposes.

Cheers,
Ari

---

From: Emil Ivov <[email-masked]>
Date: Tue, 22 Jul 2014 11:06:05 -0400

> proposed to be updated for other purposes.

The point is to have all that information without involving signalling, 
as is the case with regular nomination.

Let me ask the question the other way. Is there any reason not to do this?

Emil

-- 
https://jitsi.org

---

From: Ari Keränen <[email-masked]>
Date: Tue, 22 Jul 2014 18:11:51 -0400

> Let me ask the question the other way. Is there any reason not to do this?

Just the usual: are the benefits higher than the added complexity. Here, 
depending how it's done, the added complexity should be fairly low though.

For the benefits, currently with SIP you are allowed to release the not 
selected candidate resources after 3 seconds from concluding ICE 
(http://tools.ietf.org/html/rfc5245#section-8.3.1). For non-SIP cases 
probably some more guidance in bis would be in order. Or did you have 
some other kind of resources in mind?

Cheers,
Ari

---

From: Emil Ivov <[email-masked]>
Date: Tue, 22 Jul 2014 19:12:20 -0400

The complexity of having to handle that over signalling and the need to
implement it on every sig protocol that ever dares to use ICE is arguably
much higher than that of an extra attribute

> For the benefits, currently with SIP you are allowed to release the not
selected candidate resources after 3 seconds from concluding ICE (
http://tools.ietf.org/html/rfc5245#section-8.3.1).

And that is the whole point because currently with aggressive nomination
you simply don't know exactly when ICE has concluded.

Emil

--sent from my mobile

> For non-SIP cases probably some more guidance in bis would be in order.
Or did you have some other kind of resources in mind?

---

From: Ari Keränen <[email-masked]>
Date: Wed, 23 Jul 2014 12:30:26 -0400

On 7/22/14 7:12 PM, Emil Ivov wrote:
>
> On 22 Jul 2014 6:11 PM, "Ari Keränen" <[email-masked]
> <mailto:[email-masked]>> wrote:
>  >
>  > Just the usual: are the benefits higher than the added complexity.
> Here, depending how it's done, the added complexity should be fairly low
> though.
>
> implement it on every sig protocol that ever dares to use ICE is
> arguably much higher than that of an extra attribute

Actually I meant the complexity of implementing something like this, and 
why to do/not to do this (in any way).

>  > For the benefits, currently with SIP you are allowed to release the
> not selected candidate resources after 3 seconds from concluding ICE
> (http://tools.ietf.org/html/rfc5245#section-8.3.1).
>

So if you assume aggressive ICE has concluded after you've got your 
first USE-CANDIDATE checks done (as the text currently says), and you 
stop doing keep-alives on all except the selected candidate pair and let 
your relayed and reflexive candidates die away. You still have some time 
to switch between the candidates since the candidates are still alive 
for at least some (tens of?) seconds. Isn't that OK?

Cheers,
Ari

---

From: Justin Uberti <[email-masked]>
Date: Wed, 23 Jul 2014 15:58:42 -0400

The issue isn't just that you don't know when aggressive nomination has
ended - it's that the CONTROLLING side can't truly express its desires to
the CONTROLLED side, including use of some dynamic metric (e.g. RTT) to
choose the active candidate pair instead of PRIORITY.

With regular nomination, the CONTROLLING side has this option, but not with
aggressive nomination. This is the core issue that I want to fix, and I
would definitely want to fix this in the media plane using something like
REALLY-USE-CANDIDATE, since it may change fairly quickly as RTT values
stabilize.

There are other things that we can try to fix at the same time, e.g. the
CONTROLLED side can keep other candidate pairs warm and switch to them at
any time (via another REALLY-USE-CANDIDATE).

On Wed, Jul 23, 2014 at 12:30 PM, Ari Keränen <[email-masked]>
wrote:

> So if you assume aggressive ICE has concluded after you've got your first
> USE-CANDIDATE checks done (as the text currently says), and you stop doing
> keep-alives on all except the selected candidate pair and let your relayed
> and reflexive candidates die away. You still have some time to switch
> between the candidates since the candidates are still alive for at least
> some (tens of?) seconds. Isn't that OK?
>
>

---

From: Ari Keränen <[email-masked]>
Date: Wed, 23 Jul 2014 17:46:35 -0400

On 7/23/14 3:58 PM, Justin Uberti wrote:
> ended - it's that the CONTROLLING side can't truly express its desires
> to the CONTROLLED side, including use of some dynamic metric (e.g. RTT)
> to choose the active candidate pair instead of PRIORITY.
>
> With regular nomination, the CONTROLLING side has this option, but not
> with aggressive nomination. This is the core issue that I want to fix,
> and I would definitely want to fix this in the media plane using
> something like REALLY-USE-CANDIDATE, since it may change fairly quickly
> as RTT values stabilize.
>
> CONTROLLED side can keep other candidate pairs warm and switch to them
> at any time (via another REALLY-USE-CANDIDATE).

OK, that's an interesting case. But if you want to change candidates 
over time, this actually sounds a bit like mobility with ICE?

Cheers,
Ari

---

From: Justin Uberti <[email-masked]>
Date: Wed, 23 Jul 2014 17:51:40 -0400

That part is separable from the basic need for dynamic prioritization.

I will look at the mobility draft to see how these concepts relate.
On Jul 23, 2014 5:46 PM, "Ari Keränen" <[email-masked]> wrote:

> OK, that's an interesting case. But if you want to change candidates over
> time, this actually sounds a bit like mobility with ICE?
>
>
> Cheers,
> Ari
>
>
>

---

From: Emil Ivov <[email-masked]>
Date: Wed, 23 Jul 2014 18:00:23 -0400

> why to do/not to do this (in any way).

Yes, so did I. We are talking about the "complexity" of adding one ICE 
attribute as opposed to intertwining the states of ICE and signalling 
and making them dependent on each other.

> for at least some (tens of?) seconds. Isn't that OK?

If I assume ICE has concluded after my *first* USE-CANDIDATE and let 
everything die away then, with aggressive nomination, how am I ever 
going to get a second?

Emil

-- 
https://jitsi.org

---

From: Ari Keränen <[email-masked]>
Date: Wed, 23 Jul 2014 18:21:44 -0400

> everything die away then, with aggressive nomination, how am I ever

It takes a while before your server reflexive and relayed candidates die 
out so you have some time to get more checks through. Of course you 
shouldn't close the local sockets immediately. However, if you want to 
do that considerably (> tens of second) later, and perhaps multiple 
times, it may get more complicated (something like mobility with ICE).

Cheers,
Ari

---

From: Emil Ivov <[email-masked]>
Date: Wed, 23 Jul 2014 18:28:01 -0400

On 23.07.14, 18:21, Ari Keränen wrote:
>>>>  >>>> aggressive nomination, the controlling agent can use to notify
>>>> its
>>>> peer
>>>>  >> Let me ask the question the other way. Is there any reason not
>>>> to do
>>>> this?
>>>>  >
>>>>  >

These are exactly the kinds of hacks that implementations try to do 
today. Magic timers and proprietary logic. This is exactly what I was 
hoping we could remove by replicating the same feature in aggressive 
that we already have for regular nomination. As Justin put it:  giving a 
way to the controlling agent to communicate it's selection to the 
controlled.

It simply doesn't make sense not to have it and it would simplify things 
a lot so the argument "it would add complexity" doesn't really hold.

Emil

-- 
https://jitsi.org

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 24 Jul 2014 01:40:41 +0200

2014-07-22 17:02 GMT+02:00 Ari Keränen <[email-masked]>:
> modification to 5245), but that's something that has been already proposed
> to be updated for other purposes.

Do you mean sending the "updated SDP offer" after ICE is paired? No
please. Relying on that is a bad idea. STUN is a network protocol and
should not rely on a different signaling protocol (SIP+SDP or XXX+SDP)
to indicate nothing. The SDP (or whatever is used) is just needed to
indicate ICE parameters out of band.

And for sure, WebRTC browsers ignore at 100% the "update SDP offer
once ICE is paired".

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 24 Jul 2014 06:12:53 +0530

Hi Emil,

It is better to handle through signaling as it provides to flexibility in the application (like forking usecase). In case of pushing the intelligence within ICE will just move the portion of the signaling to ICE in case the application is required to know.

Please note that the signaling protocol which choose not to indicate it based on the specific signaling protocol design.

Thanks
Partha

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Emil Ivov
> Sent: Thursday, July 24, 2014 3:58 AM
> To: Ari Keränen
> Cc: mmusic
> Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
> 
> 
> 
> >>>>  >>>> In London we mentioned the option of adding a new attribute
> that,
> >>>> during
> >>>>  >>>> controlling agent send a second USE-CANDIDATE once
> aggressive
> >>>> nomination
> >>>>  >>>> converges.
> >>>>  >>>
> >>>>  >>>
> >>>>  >>> Did you consider using the updated offer to indicate that
> you're
> >>>> really
> >>>> Here, depending how it's done, the added complexity should be
> fairly
> >>>> low
> >>>> though.
> >>>>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 23 Jul 2014 23:12:24 -0400

It is important to understand that this proposed approach doesn't change
the interactions with signaling at all.

Currently, when doing regular nomination, the CONTROLLING can use its own
policy to decide which active candidate pair to use, as is described in
RFC5245, S 8.1.1.1. This is not possible when doing aggressive nomination.
The solution I am proposing fixes this issue.

On Wed, Jul 23, 2014 at 8:42 PM, Parthasarathi R <[email-masked]

> Hi Emil,
>
> It is better to handle through signaling as it provides to flexibility in
> the application (like forking usecase). In case of pushing the intelligence
> within ICE will just move the portion of the signaling to ICE in case the
> application is required to know.
>
> Please note that the signaling protocol which choose not to indicate it
> based on the specific signaling protocol design.
>
> Thanks
> Partha
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 24 Jul 2014 10:22:38 +0200

2014-07-24 2:42 GMT+02:00 Parthasarathi R <[email-masked]>:
> It is better to handle through signaling as it provides to flexibility in the application (like forking usecase).

No, it is not. So 5245bis si supposed to split ICE network protocol
and SDP, and you propose that a new feature must depend, again, on the
signaling protocol? No way.

And the forking usecase (so you mean the "SIP forking usecase") is
perfectly achiveable via a new STUN attribute (by sending a request
containing it to the specific "SIP forked dialog").

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ari Keränen <[email-masked]>
Date: Thu, 24 Jul 2014 09:37:00 -0400

> And for sure, WebRTC browsers ignore at 100% the "update SDP offer

Yes, I meant that the updated (SDP) offer could make sense as an 
indicator for being done since it is already there. But if it isn't 
actually sent, doing it just for the sake of this doesn't sound very 
smart. And perhaps the bundling of these two isn't that good idea to 
start with.

Cheers,
Ari

---

From: Ari Keränen <[email-masked]>
Date: Thu, 24 Jul 2014 10:03:20 -0400

> way to the controlling agent to communicate it's selection to the

We could of course recommend some values on how long to wait to take 
away some of the magic.

> a lot so the argument "it would add complexity" doesn't really hold.

Makes sense. I'm still wondering what's the best way to do this though.

Would the semantics of the new attribute be "I'm no longer trying to 
find better candidate pairs; use the highest priority with 
USE-CANDIDATE" or "don't use the highest priority pair but use X", or 
something else?

Cheers,
Ari

---

From: Emil Ivov <[email-masked]>
Date: Thu, 24 Jul 2014 10:20:57 -0400

On Thu, Jul 24, 2014 at 10:03 AM, Ari Keränen <[email-masked]> wrote:
> We could of course recommend some values on how long to wait to take away
> some of the magic.
>
>
> Would the semantics of the new attribute be "I'm no longer trying to find
> better candidate pairs; use the highest priority with USE-CANDIDATE" or
> "don't use the highest priority pair but use X", or something else?

USE-CANDIDATE-CONFIRMATION (or whatever name we want) sounds like the
most unambiguous and easy to implement option.

I don't think priorities should play a role at this stage, just as
they don't with regular nomination.

Resending USE-CANDIDATE looks slightly more messy to me (especially
when trying to make sense of wireshark traces) but it would still
work.

Emil

-- 
https://jitsi.org

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 24 Jul 2014 16:43:22 +0200

> they don't with regular nomination.

Just wondering:

What about re-sending the chosen ICE Request but with a higher
PRIORITY at that point? I mean:

  Req1 (USE-CANDIDATE, PRIORITY: 1234)  -->
  Req2 (USE-CANDIDATE, PRIORITY: 2345)  -->
  (let's choose the first one)
  Req1 (USE-CANDIDATE, PRIORITY: 9999)  -->

For sure you have already thought about this and it is invalid, just
wondering if I miss something. :)
-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Emil Ivov <[email-masked]>
Date: Thu, 24 Jul 2014 10:48:51 -0400

> wondering if I miss something. :)

Well, if you are going to resend it at all then you don't even need to
change priority. The simple fact that you are re-confirming it should
be enough of an indication. That's actually the second option I was
referring to in my previous mail and it would work but I just find it
inconvenient when analysing wireshark traces (i.e., looking for
USE-CANDIDATE-CONFIRMATION is easier than trying to count the number
of USE-CANDIDATEs for a specific pair and then trying to distinguish
retransmissions from new transactions).

Emil

-- 
https://jitsi.org

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 24 Jul 2014 17:08:19 +0200

2014-07-24 16:48 GMT+02:00 Emil Ivov <[email-masked]>:
> be enough of an indication.

I don't think it should work. The ICE server should select the request
with highest PRIORITY regardless it receives later a new one with less
PRIORITY. This is clear in the RFC. And this is because it is supposed
that both peers agree on selecting the request-response with higher
PRIORITY, regardless which one arrives before.

This makes sense. Let's assume requests come in this order:

1)

   Req1-good-connection PRIORITY: 9000  -->
   Req2-bad-connection PRIORITY: 1000  -->

should the server chose Req2? not at all.

2)

   Req2-bad-connection PRIORITY: 1000  -->
   Req1-good-connection PRIORITY: 9000  -->

server should choose Req1 once it arrives.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Emil Ivov <[email-masked]>
Date: Thu, 24 Jul 2014 11:15:09 -0400

On Thu, Jul 24, 2014 at 11:08 AM, Iñaki Baz Castillo <[email-masked]> wrote:
> I don't think it should work.

It wouldn't work with existing implementations. The point is to define
the spec in a way that makes it work in future implementations.

> The ICE server should select the request
> with highest PRIORITY

I am not sure what you mean by ICE server.

> regardless it receives later a new one with less

This is not true for regular nomination where the nominated candidate
is chosen solely based on the USE-CANDIDATE option.

The point is to create an unambiguous

> server should choose Req1 once it arrives.

I think you are confusing multiple received USE-CANDIDATE options for
*different* candidate pairs (which is what happens with aggressive
nomination) with receiving a second USE-CANDIDATE option for *the
same* candidate pair.

Emil

-- 
https://jitsi.org

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 24 Jul 2014 17:33:08 +0200

> I am not sure what you mean by ICE server.

The ICE agent receiving the requests. Imagine a ICE-Lite server which
is just a "server".

> is chosen solely based on the USE-CANDIDATE option.

I just mean aggressive nomination.

> nomination) with receiving a second USE-CANDIDATE option for *the

Humm, not :)

- ICE-Lite servers opens UDP socket in ports 1111 and 2222.

- Client sends:

  ICE-Req-1 USE_CANDIDATE PRIORITY 555  -->  port 1111
and later:
  ICE-Req-2 USE_CANDIDATE PRIORITY 666  -->  port 2222

I just mean that in this case the ICE-Lite server must first select
Req1--1111 pair and then move to Req2--2222 pair.

But in this case:

  ICE-Req-1 USE_CANDIDATE PRIORITY 666  -->  port 1111
and later:
  ICE-Req-2 USE_CANDIDATE PRIORITY 555  -->  port 2222

the ICE-Lite server must first select Req1--1111 pair and would NOT
move to Req1--2222 pair.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Emil Ivov <[email-masked]>
Date: Thu, 24 Jul 2014 11:46:02 -0400

> The ICE agent receiving the requests.  Imagine a ICE-Lite server which

Well ok, but an ICE lite agent doesn't really get to select anything. It 
just has to try and understand what the controlling agent has selected. 
Currently it would do that based on priority but this is suboptimal. 
That's what we are trying to improve.

>> nomination) with receiving a second USE-CANDIDATE option for *the

Getting multiple USE-CANDIDATES on *different* candidates is simply the 
definition of aggressive nomination. We are not discussing this.

The "second" USE-CANDIDATE that mails in this thread have referred to 
was about the possibility to do a second USE-CANDIDATE on the *same* 
pair as an indication for selecting that candidate. Neither of your 
examples below display this.

> the ICE-Lite server must first select Req1--1111 pair and would NOT

The point is that, once the two checks above succeed, the controlling 
agent may choose to send an additional *third* request on *any* of the 
two in order to communicate its desire to use that candidate pair.

This may be the higher priority candidate pair or it may be another one 
(e.g., if it gave a better RTT) and its choice would depend on the 
controlling agent.

Is it clearer now?

Emil

-- 
https://jitsi.org

---

From: Justin Uberti <[email-masked]>
Date: Thu, 24 Jul 2014 13:16:58 -0400

The PRIORITY attribute is only for determining priority for peer-reflexive
candidates. Using it to change priority for other types of candidates would
be a significant change in semantics; I don't want to go there.

On Thu, Jul 24, 2014 at 11:46 AM, Emil Ivov <[email-masked]> wrote:

> Currently it would do that based on priority but this is suboptimal. That's
> what we are trying to improve.
>
>
> The "second" USE-CANDIDATE that mails in this thread have referred to was
> about the possibility to do a second USE-CANDIDATE on the *same* pair as an
> indication for selecting that candidate. Neither of your examples below
> display this.
>
>
> agent may choose to send an additional *third* request on *any* of the two
> in order to communicate its desire to use that candidate pair.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 31 Jul 2014 13:17:44 +0200

2014-07-24 17:46 GMT+02:00 Emil Ivov <[email-masked]>:
> The point is that, once the two checks above succeed, the controlling agent
> may choose to send an additional *third* request on *any* of the two in
> order to communicate its desire to use that candidate pair.
>

Sorry for the delay (holidays). Yes, clearer, thanks a lot.

The "third request in order to communicate its desire to use that
candidate pair" seems to me like an "ICE restart" without signaling
(but just STUN protocol).

In my example above (once the server has replied to both USE-CANDIDATE
and "assumed" a selected pair by following RFC 5764 procedures) the
server may initiate DTLS (let's assume it gets the setup:active role).
After 10ms the client sends a new USE-CANDIDATE with the new proposed
attribute REALLY-USE-THIS-CANDIDATE while in the middle of the DTLS
handshake.

Now what? How to deal with that? DTLS reset once a
REALLY-USE-THIS-CANDIDATE is received? that must be clarified.

And how should the ICE controlled determine that it must wait for the
optional new ICE request after common RFC 5764 procedures? a new
ice-option attribute in SDP that the remote peer may not understand?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 31 Jul 2014 13:31:03 +0200

2014-07-24 17:46 GMT+02:00 Emil Ivov <[email-masked]>:
> definition of aggressive nomination. We are not discussing this

Just a question:

- peerA sets two interfaces for ICE and peerB just one.
- peerA uses aggressive ICE.

Does it mean that peerA will send two ICE requests with USE-CANDIDATE
from its two interfaces to the single interface of peerB? or not? That
was my point all the time.

Thanks.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 31 Jul 2014 13:34:45 +0200

> be a significant change in semantics; I don't want to go there.

Correct me if I'm wrong, but a ICE-Lite server does not even need to
know about the ICE parameters it signals to the peer and it receives
form the peer (but just its own ufrag and passwd) and can determine
which is the selected pair by just inspecting the PRIORITY attribute
in received ICE requests with USE-CANDIDATE.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 31 Jul 2014 12:11:22 -0700

> in received ICE requests with USE-CANDIDATE.
ICE Lite doesn't care about PRIORITY. Since you have to use regular
nomination with ICE Lite, it just uses the single pair on which
USE-CANDIDATE is set.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 1 Aug 2014 00:18:56 +0200

> nomination with ICE Lite, it just uses the single pair on which

Yes, sorry, I was confused given that Firefox does not understand
ICE-lite and performs aggressive nomination even when the peer is
ICE-Lite :)

-- 
Iñaki Baz Castillo
<[email-masked]>