Re: [MMUSIC] Generalizing the aggressive nomination bugfix

On Mar 12, 2014, at 9:25 AM, "Pal Martinsen (palmarti)" <palmarti@cisco.com> wrote:

> 
> On 12 Mar 2014, at 00:49, Dan Wing <dwing@cisco.com> wrote:
> 
>> 
>> On Mar 10, 2014, at 6:21 AM, Justin Uberti <juberti@google.com> 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. 

Yes, I like that.  Probably best to signal in ICE rather than in SDP, for lots of reasons, too.  That idea is similar (but not identical) to MPTCP's MP_PRIO to indicate backup/standby path, http://tools.ietf.org/html/rfc6824#section-2.5.

> 
>> 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?) :-)
> 
> It is an interesting problem to solve. 

I don't think it is solvable with protocols, except to allow both ends to have enough information to make a smarter policy decision.

-d

> 
> .-.
> Pål-Erik
> 
>> 
>> -d
>> 
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> 