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

["Pal Martinsen (palmarti)" <[e-mail]>]

> On 07 Mar 2015, at 03:23, Ari Keränen <[e-mail]> 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)