Re: [MMUSIC] Generalizing the aggressive nomination bugfix

[Dan Wing <[e-mail]>]

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

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

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