Re: [MMUSIC] Comments on draft-martinsen-mmusic-ice-dualstack-fairness-02

[Ari Keränen <[e-mail]>]

On 09/03/15 01:48, Pal Martinsen (palmarti) wrote:
>> On 07 Mar 2015, at 03:23, Ari Keränen <[e-mail]>
>> wrote:
>> 3.  Improving ICE Multihomed Fairness
>>
>> Candidates from a interface known to the application to provide
>> unreliable connectivity SHOULD get a low candidate priority.  This
>> ensures they appear near the end of the candidate list, and would
>> be the last to be tested during the connectivity check phase.
>> This allows candidate pairs more likely to succeed to be tested
>> first.
>>
>> I think this is already covered by regular ICE (e.g., in RFC5245
>> section 4.1.2.1) and I would not go as far as to say one SHOULD
>> prefer a reliable interface over e.g., fast and cheap one.
>
> The idea was to get a working candidate pair as quick as possible. I
> did not take into account that the priority will also affect what
> candidate pair will be chosen when ICE is finished.

The candidate that works most likely would be the relayed candidate. But 
obviously preferring that in general is not a good idea.

> The continuous  nomination proposal will solve this (Hopefully). My
> goal with the draft is to sort the ICE checklist in the most optimal
> manner so having a usable (but maybe not preferable?) candidate pair
> as quick as possible without relying on the default candidate. (Maybe
> mentioning this in the introduction would be helpful?)

I assumed the goal of the draft was to fix/alleviate the problem with 
broken IPv6 paths.

Considering that continuous nomination work has just started, relying on 
that mechanism to fix something that is defined here sounds risky. And 
hopefully this fix applies also to vanilla ICE.

>> Therefore, I would recommend to keep the scope of this document in
>> dual-stack.
>>
>
> This is where we need to have a WG discussion. My perception from
> last IETF meeting was that just solving the dual-stack problem was a
> bit narrow. Solving the problem regarding unreliable tunnels
> (Interfaces) would add more value.

IPv6 provided by tunneling, which we discussed at the last meeting, is 
in the scope of the draft. Whether, or to what extent, we want or need 
to address other tunneling issues, I'm not sure.

> Dual-stack is really just a special case of multihomed. Because of
> this it might make sense to broaden the scope of the draft to include
> multihomed devices?

In that area also the MIF WG has done a fair amount of work. For 
example, this seems relevant:
https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-06

Reviewing the work done in that area would be a good idea.


Cheers,
Ari