Subject: Re: [Ice] Mirja Kühlewind's Discuss on draft-ietf-ice-dualstack-fairness-04: (with DISCUSS and COMMENT)

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 5 Sep 2016 08:23:02 +0000

> On 31 Aug 2016, at 14:31, Mirja Kuehlewind <[email-masked]> wrote:
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I'm willing to resolve my discuss quickly but I would like to start some
> discussion:
> 
> To me the recommenations given in this doc are not very clear. To my
> understanding are there two recommenations:
> 
> 1) intermingle IPv4 and IPv6 addresses, and
> 2) put lower priority for adresses that are know to have connectivity
> problem.
> 
Correct.

> However, that leaves tons of open questions to the implementor, e.g.
> - How many IPv6 addresses should I have before the first IPv4?
> - How do I measure/track that an interface has connectitivy problems:
> connectivity failed once, or twice, or X-times? How long do I keep this
> track: 1h, one day, one week, forever?
> 
> Would it be possible to be more specific and give further guidance? E.g.
> how are these points implemented in the existing implementations?
> 
This was the original goal when we started working on this draft. As work progressed it was clear that getting consensus on a specific algorithm or any specific value recommendations would be very hard to achieve. Some people care about IPv4 others about IPv6 and so on.  But I do think since this is IETF work we have an obligation to push IPv6 friendly solutions.

So the outcome of the work in the WG was a BCP that acknowledges that there is a problem that implementors should be aware of with guidelines on what values from the ICE RFC could safely be altered to fix the problem. 

I would also expect any explicit guidelines to change over time. I think implementers are getting used to that now and are collecting metrics that they can use to dynamically change the values. 

We can put wording like ”a good starting point might be ..”, and add some text regarding metrics and changing conditions into the draft. 

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Further, I think the term 'fairness' is just wrong here. The goal is to
> avoid delay in case there are connectivity problems with IPv6 in general,
> while still prioritizating IPv6. For me, that's nothing about fairness.
> 
> 
That is the goal, but to achieve that goal we need a “fair” distribution if IPv4 and IPv6 candidates in the checklist.
Or a solution that is “free from bias or injustice”. (from http://www.dictionary.com/browse/fairness)

Based on that (I am not a native speaker..), I thought the name was fine. I do agree that it might not be perfect or even close, so any new suggestions would be much appreciated. 

Thanks for thorough review. Much appreciated. 

.-.
Pål-Erik

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 5 Sep 2016 14:29:33 -0500

Hi, Pal,

On Mon, Sep 5, 2016 at 3:23 AM, Pal Martinsen (palmarti) <[email-masked]
> wrote:

> This was the original goal when we started working on this draft. As work
> progressed it was clear that getting consensus on a specific algorithm or
> any specific value recommendations would be very hard to achieve. Some
> people care about IPv4 others about IPv6 and so on.  But I do think since
> this is IETF work we have an obligation to push IPv6 friendly solutions.
>
> So the outcome of the work in the WG was a BCP that acknowledges that
> there is a problem that implementors should be aware of with guidelines on
> what values from the ICE RFC could safely be altered to fix the problem.
>
> I would also expect any explicit guidelines to change over time. I think
> implementers are getting used to that now and are collecting metrics that
> they can use to dynamically change the values.
>
> We can put wording like ”a good starting point might be ..”, and add some
> text regarding metrics and changing conditions into the draft.

This isn't my Discuss, so please focus on Mirja's feedback, but I find this
explanation very helpful, and think your suggestion in this paragraph ( ^^
) is a good one. Mirja and I did talk about this aspect of the draft during
IESG evaluation, and I thought her Discuss was pointed in the right
direction.

So, thank you.

Spencer

> That is the goal, but to achieve that goal we need a “fair” distribution
> if IPv4 and IPv6 candidates in the checklist.
> Or a solution that is “free from bias or injustice”. (from
> http://www.dictionary.com/browse/fairness)
>
> Based on that (I am not a native speaker..), I thought the name was fine.
> I do agree that it might not be perfect or even close, so any new
> suggestions would be much appreciated.
>
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 6 Sep 2016 10:57:30 +0200

Hi,

I don't think this document must provide specific algorithms but at least the 
recommendations given should be clear. Currently they are quite lost in 
explanation text. Maybe have a new section that clearly spells out the 
guidelines? (And maybe also check for redundancy because bringing it more to 
the point can also help clarity.)

Fairness is a problematic term because there are various aspects of fairness 
where it can easily happen that different people have different ideas about 
what that means. As I said I also think this has nothing to do with fairness 
because the goal is still to slightly favor IPv6 but reduce delay. Why don't 
you just call it guidelines as done in the abstract?

Mirja