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

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

On 12/03/15 01:29, Pal Martinsen (palmarti) wrote:
>
>> On 11 Mar 2015, at 00:23, Ari Keränen <[e-mail]> wrote:
>>
>> 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.
>
> Yes. And the draft stays well away from doing anything with the type preference.
> If you had lots of IPv6 relayed candidates and a few IPv4 candidates the fairness algorithm would make sure those candidates was mixed together.
>
> In other words each block of type preferences (HOST, RFLX and RELAY) would get their IPv4 and IPv6 candidates more fairly sorted.
>
> I think the draft might be better at explaining that.
>
>>
>>> 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.
>>
>
> Yes, you are right. Using optimal was way to strong.
>
> One of the design philosophy behind ICE is that it should make no assumptions regarding the network. In my opinion it does assume that IPv6 works better than IPv4 by putting  all the IPv6 candidates in front of the IPv4 candidates in the checklist.

ICE prefers IPv6 candidates to facilitate the transition to IPv6, not 
necessarily because they are assumed to (currently) work better. That 
said, they ended up being occasionally considerably worse and now we're 
doing this work to fix that problem.

>> 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.
>>
>
> Agreed.
>
> Having a pointer in the draft to ICE section 8 Concluding ICE. Using this with regular nomination works without any problems as the agent can choose what pair to nominate. With aggressive nomination I think there is a chance that the pair being used is not the preferred one. Following IETF guidelines for IPv6 transitions I think they say something about IPv6 should be preferred over IPv4, this draft will break that with aggressive nomination. I think that is a minor problem, the HOST, RFLX and RELAY priorities are still intact.

We should consider carefully also in this draft how to make sure this 
does not hurt the transition to IPv6. The fact that we do still check 
some IPv6 addresses before IPv4 addresses at least helps, but I wonder 
if we can do more. Can we perhaps use history information of v6 
brokenness like in the original happy eyeballs and occasionally give v6 
again higher priority?

>>>> 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.
>>
>
> Ok. Deprioritising certain types of IPv6 addresses was possible in the previous revisions of the draft.
>
> I will be happy to stay focused on IPv4/IPv6 dual stack without expanding the draft to deal with more general. But both of them needs to play with the local_preference value so combining them would make it easier for developers.

And that is already allowed by RFC5245, and will be allowed by 5245bis. 
But let's make sure we don't break that possibility here. And focus with 
this draft on the dual-stack issue.


Cheers,
Ari

>>> 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.
>>
> Yes, at least one of the authors of the draft is active in that group. The draft started out as ICE-happy-eyeballs, but we moved away from that solution so a renaming to fairness was appropriate.
>
> .-.
> Pål-Erik
>
>>
>> Cheers,
>> Ari
>