Subject: [MMUSIC] Generalizing the aggressive nomination bugfix

From: Justin Uberti <[email-masked]>
Date: Mon, 10 Mar 2014 06:21:18 +0000

In the WG session on Monday, Ari mentioned that the aggressive nomination
bug of controller and controlled not agreeing on the candidate pair to use
could be rectified by having the controlled side switch its preferred
candidate pair to be the one that it received secure media on (or if not
using controlled media, when the controlling side’s ICE checks finally got
through).

I think there is an opportunity here to improve the overall flexibility of
ICE. Currently, Regular Nomination allows the controller to have a fair
amount of discretion in choosing which candidate pair it wants to pick; it
could use metrics such as RTT, or perhaps one of the values mentioned in
DISCUSS to make its selection, instead of using the static PRIORITY value.
Aggressive Nomination, while faster in initially establishing media, does
not afford this same discretion; according to 5245, S 8.1.1.2, ICE uses the
highest PRIORITY candidate pair. So it would be great if there was a way to
allow the controller have the same discretion for choosing the selected
candidate pair, while also doing Aggressive Nomination.

I think this can easily be done using Ari’s solution in a general way. In
short, any time secure media packets are received by the controlled side,
it should use that candidate pair to send its own media. (Secure media is
needed to prevent an attacker from tricking the controlled side into
sending media to an arbitrary address.) If secure media is not used, the
controller could include a new attribute, something like a new
PREFERRED-CANDIDATE attribute (or perhaps an updated PRIORITY attribute,
set to the max ICE priority), to tell the controlled side which candidate
pair should be used.

This would allow the controller to do periodic RTT checks, perhaps using
the ICE consent mechanism, and dynamically change the media path as needed.

---

From: Dan Wing <[email-masked]>
Date: Tue, 11 Mar 2014 23:49:23 +0000

On Mar 10, 2014, at 6:21 AM, Justin Uberti <[email-masked]> wrote:

> In the WG session on Monday, Ari mentioned that the aggressive nomination bug of controller and controlled not agreeing on the candidate pair to use could be rectified by having the controlled side switch its preferred candidate pair to be the one that it received secure media on (or if not using controlled media, when the controlling side’s ICE checks finally got through).
> 
> I think there is an opportunity here to improve the overall flexibility of ICE. Currently, Regular Nomination allows the controller to have a fair amount of discretion in choosing which candidate pair it wants to pick; it could use metrics such as RTT, or perhaps one of the values mentioned in DISCUSS to make its selection, instead of using the static PRIORITY value. Aggressive Nomination, while faster in initially establishing media, does not afford this same discretion; according to 5245, S 8.1.1.2, ICE uses the highest PRIORITY candidate pair. So it would be great if there was a way to allow the controller have the same discretion for choosing the selected candidate pair, while also doing Aggressive Nomination.
> 
> I think this can easily be done using Ari’s solution in a general way. In short, any time secure media packets are received by the controlled side, it should use that candidate pair to send its own media. (Secure media is needed to prevent an attacker from tricking the controlled side into sending media to an arbitrary address.) If secure media is not used, the controller could include a new attribute, something like a new PREFERRED-CANDIDATE attribute (or perhaps an updated PRIORITY attribute, set to the max ICE priority), to tell the controlled side which candidate pair should be used.
> 
That all sounds good.

> This would allow the controller to do periodic RTT checks, perhaps using the ICE consent mechanism, and dynamically change the media path as needed.
> 

I think we need additional signaling to switch interfaces, because each endpoint needs to participate in the decision (e.g., draft-wing-mmusic-ice-mobility).  For example, the controlling endpoint might have unmetered Internet access, whereas the other endpoint has fast metered Internet (e.g., LTE) and slower unmetered Internet (e.g., DSL) -- but if the controlling endpoint effectively ignores the ICE priorities in favor of round trip time calculations, the controlled endpoint will use LTE.  ICE priorities allows both ends to indicate their preferences.  We might need something more than ICE priorities, too, or a way to strongly say an interface is not preferred (because that interface is metered).

-d

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 12 Mar 2014 16:25:27 +0000

On 12 Mar 2014, at 00:49, Dan Wing <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 10, 2014, at 6:21 AM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

If the PREFERRED-CANDIDATE attribute also had a priority associated with it, it would be possible to mach up candidate pairs that would suite both agents. Something like a simplified version of the pair priority formula. Some clever rules to make sure we always will end up with a pair with connectivity might also be needed.

That all sounds good.

If we end up in a situation where connectivity can only happen if either A or B is on a metered interface, how should we decide who have to pay? (Based on link cost or salary?) :-)

It is an interesting problem to solve.

.-.
Pål-Erik

-d

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

---

From: Justin Uberti <[email-masked]>
Date: Wed, 12 Mar 2014 09:27:33 -0700

On Tue, Mar 11, 2014 at 4:49 PM, Dan Wing <[email-masked]> wrote:

> I think we need additional signaling to switch interfaces, because each
> endpoint needs to participate in the decision (e.g.,
> draft-wing-mmusic-ice-mobility).  For example, the controlling endpoint
> might have unmetered Internet access, whereas the other endpoint has fast
> metered Internet (e.g., LTE) and slower unmetered Internet (e.g., DSL) --
> but if the controlling endpoint effectively ignores the ICE priorities in
> favor of round trip time calculations, the controlled endpoint will use
> LTE.  ICE priorities allows both ends to indicate their preferences.  We
> might need something more than ICE priorities, too, or a way to strongly
> say an interface is not preferred (because that interface is metered).
>
> 5245 seems to indicate that the controlling endpoint is in the driver's
seat, as explained in S 2.6:

   More fundamentally, however, the prioritization
   defined by this specification may not yield "optimal" results.  As an
   example, if the aim is to select low-latency media paths, usage of a
   relay is a hint that latencies may be higher, but it is nothing more
   than a hint.  An actual round-trip time (RTT) measurement could be
   made, and it might demonstrate that a pair with lower priority is
   actually better than one with higher priority.

   Consequently, ICE assigns one of the agents in the role of the
   CONTROLLING AGENT, and the other of the CONTROLLED AGENT.  The
   controlling agent gets to nominate which candidate pairs will get
   used for media amongst the ones that are valid.

I agree it would be useful to allow the controlled side to give some
hints to the controlling side though.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 12 Mar 2014 09:30:27 -0700

On Wed, Mar 12, 2014 at 9:25 AM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

>
>  On 12 Mar 2014, at 00:49, Dan Wing <[email-masked]> wrote:
>
>
>  In the WG session on Monday, Ari mentioned that the aggressive
> nomination bug of controller and controlled not agreeing on the candidate
> pair to use could be rectified by having the controlled side switch its
> preferred candidate pair to be the one that it received secure media on (or
> if not using controlled media, when the controlling side’s ICE checks
> finally got through).
>
>  If the PREFERRED-CANDIDATE attribute also had a priority associated with
> it, it would be possible to mach up candidate pairs that would suite both
> agents. Something like a simplified version of the pair priority formula.
> Some clever rules to make sure we always will end up with a pair with
> connectivity might also be needed.
>
>   That all sounds good.
>
>  If we end up in a situation where connectivity can only happen if either
> A or B is on a metered interface, how should we decide who have to pay?
> (Based on link cost or salary?) :-)
>

In this case I would expect the controlling side wins, unless we determine
that we need something more complex.

---

From: Dan Wing <[email-masked]>
Date: Wed, 12 Mar 2014 09:33:08 -0700

> If the PREFERRED-CANDIDATE attribute also had a priority associated with it, it would be possible to mach up candidate pairs that would suite both agents. Something like a simplified version of the…

Yes, I like that.  Probably best to signal in ICE rather than in SDP, for lots of reasons, too.  That idea is similar (but not identical) to MPTCP's MP_PRIO to indicate backup/standby path, http://tools.ietf.org/html/rfc6824#section-2.5.

> It is an interesting problem to solve. 

I don't think it is solvable with protocols, except to allow both ends to have enough information to make a smarter policy decision.

-d

>> [email-masked]

---

From: Dan Wing <[email-masked]>
Date: Wed, 12 Mar 2014 09:35:35 -0700

On Mar 12, 2014, at 9:27 AM, Justin Uberti <[email-masked]> wrote:

> 5245 seems to indicate that the controlling endpoint is in the driver's seat, as explained in S 2.6:
> 
> 
> I agree it would be useful to allow the controlled side to give some hints to the controlling side though. 

I agree the controlling side is controlling.  But it needs to be influenced by the controlled side, or else users will have to manually toggle their interfaces on/off to avoid overage charges.  That toggling is a p.i.t.a.

-d

---

From: Justin Uberti <[email-masked]>
Date: Wed, 12 Mar 2014 22:11:59 -0700

On Wed, Mar 12, 2014 at 9:35 AM, Dan Wing <[email-masked]> wrote:

>> I think there is an opportunity here to improve the overall flexibility
>> of ICE. Currently, Regular Nomination allows the controller to have a fair
> I agree the controlling side is controlling.  But it needs to be
> influenced by the controlled side, or else users will have to manually
> toggle their interfaces on/off to avoid overage charges.  That toggling is
> a p.i.t.a.
>
>
Agreed. The ability to mark an interface as only-if-absolutely-necessary
seems like it would suffice. The controlling side would then only switch to
such a candidate if no other pair was viable, similar to the handling of
backup paths in 6824.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Mar 2014 09:57:06 -0700

> such a candidate if no other pair was viable, similar to the handling of

That might be a useful function to exploit to shift traffic away from
relays as well.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 14 Mar 2014 10:38:01 -0700

> That might be a useful function to exploit to shift traffic away from

That seems more nuanced. If you are getting a better RTT running through a
relay, the app will probably want to use it, so we would need some way to
specify that a relay is 'only-if-needed' or not (either in RTCIceServer, or
part of TURN)

---

From: Justin Uberti <[email-masked]>
Date: Sat, 15 Mar 2014 08:21:43 -0700

What do you suggest as next steps here? This seems like something that
should go into ICE-bis; should this be filed as errata against 5245, or
written up as a separate I-D?