Re: [MMUSIC] Generalizing the aggressive nomination bugfix

[Justin Uberti <[e-mail]>]

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

>
>  On 12 Mar 2014, at 00:49, 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.
>
>
>  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.
>
>  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).
>
>
>  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.