Re: [MMUSIC] Generalizing the aggressive nomination bugfix

[Dan Wing <[e-mail]>]

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).

-d