Re: [MMUSIC] Generalizing the aggressive nomination bugfix

[Justin Uberti <[e-mail]>]

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

>
> On Mar 10, 2014, at 6:21 AM, Justin Uberti <[e-mail]> 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).
>
> 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.