Re: [MMUSIC] Generalizing the aggressive nomination bugfix

[Justin Uberti <[e-mail]>]

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

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