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

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 9 Mar 2015 08:48:13 +0000

> On 07 Mar 2015, at 03:23, Ari Keränen <[email-masked]> wrote:
> 
> Hi,
> 
> Here's some comments on the latest "ICE IPv4/IPv6 Dual Stack Fairness" draft.
> 

[cut]
Thanks for the editorial comments. Will incorporate those. 
> 
> 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 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?)

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

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?

> 
> 6.  Example Algorithm for Choosing the Local Preference
> 
>   Ri:  Reliable interface.  A reliable interface known by the
>      application to provide reliable connectivity should set this value
>      to 1.  Interfaces known to provide unreliable connectivity should
>      set this to 0.  (Allowed values are 0 and 1)
> 
> Having reliability as a binary metrics sounds a bit restrictive. Would it be possible (and make sense) to have more levels of reliability?
> 
I did consider not making it binary. But then I decided that the number of interfaces would be fairly low, and the simplicity of just having it as a binary value would be worth it. Also keep in mind that the agent can set this value when it starts ICE. So if the clients knows that tunnel XYZ works well from location ABC it can set the interface reliability accordingly. (Or using SSID to determine if the WiFi interface should be considered reliable or unreliable.)

> Cheers,
> Ari (as individual)

---

From: Ari Keränen <[email-masked]>
Date: Tue, 10 Mar 2015 16:23:26 -0700

On 09/03/15 01:48, Pal Martinsen (palmarti) wrote:
>> 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.

> 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

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 12 Mar 2015 08:29:40 +0000

> On 11 Mar 2015, at 00:23, Ari Keränen <[email-masked]> wrote:
> 

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. 

> I assumed the goal of the draft was to fix/alleviate the problem with 

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. 

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

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

> 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

---

From: Ari Keränen <[email-masked]>
Date: Mon, 16 Mar 2015 19:18:58 -0700

> 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 candidate…

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.

> 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 nominatio…

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?

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

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