Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-dualstack-fairness-02

From: "Ben Campbell" <[email-masked]>
Date: Tue, 03 May 2016 12:25:52 -0500

Hi,

I apologize for the delay. My schedule over the last couple of weeks has 
been disrupted by some family issues. I am ramping back up now.

So, TL;DR: I think the working group needs to have a little more 
discussion about the status and purpose of this draft, and how it 
relates to ICEBis. More details below.

On 19 Apr 2016, at 6:37, Pal Martinsen (palmarti) wrote:

> On 19 Apr 2016, at 08:36, Ben Campbell 
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi,
>
> This is my AD Evaluation of draft-ietf-ice-dualstack-fairness-02. I 
> find the draft readable and understandable, but I have some comments 
> and questions. I'd like to resolve the major comments prior to IETF 
> last call.
>
> Major:
>
> The draft is now informational, but the milestone is for PS. I see the 
> minutes from Prague say the wg agreed to make the change, but that 
> doesn't say why, and I failed to find any discussion of that on the 
> list. Can anyone remind me of the reasoning? (This interacts with my 
> next comment…)
>
> Just for clarity I will summarise what I see as the key “events” 
> of the draft. (I might be wrong so of others see it differently please 
> correct me)
>
> - Started as an DualStack Happy Eyeballs solution that would give IPv6 
> a head start.
> - Several attempts to get a happy eyeballs algorithm working failed. 
> And we discovered that it would be very difficult to get right in all 
> the various scenarios. Think the “consensus in the hallways” was 
> to let each application deal with it as they would know more of what 
> was important to them.
> (http://www.ietf.org/proceedings/92/minutes/minutes-92-mmusic#h.v0jtwu5re90f)
> <http://www.ietf.org/proceedings/92/minutes/minutes-92-mmusic#h.v0jtwu5re90f>- 
> Since the draft only contains guidelines on how an application should 
> deal with dual-stack it made sense to make it informational.
> (http://www.ietf.org/proceedings/93/minutes/minutes-93-mmusic#h.34ilx3y4vkbd)

The right choice here depends on what the working group expects the 
draft to accomplish. I think informational works if we want to tell 
implementors about some things they can do if they care. If, on the 
other hand, we want to actually encourage implementors to implement 
this, then I'm not sure informational is the right choice. Did the WG 
consider BCP?

>
>
>
> I am confused about the relationships among this draft, RFC 5245, 
> 5245bis, and RFC 6724. Section 1 of this draft seems to say that it 
> recommends against following the requirement in 5245 that says dual 
> stack hosts SHOULD follow the precedence in 6724. Normally, that would 
> require this draft to update 5245, which would require it to be 
> standards track.
>
> But on the other hand, I am not entirely convinced anything here 
> really changes that SHOULD, since 6724 explicitly says:
>
>  "The selection rules specified in this document MUST NOT be construed
>   to override an application or upper layer’s explicit choice of a
>   legal destination or source address."
>
> Unfortunately, I think this puts things in a grey area, due to 
> ambiguous wording in 5245. So I think this draft either needs to 
> update 5245, or it needs to explain why the guidance here does not 
> conflict with that SHOULD.
>
> This was at least discussed in IETF90, 
> http://www.ietf.org/proceedings/90/minutes/minutes-90-mmusic#h.6fijdpveanaa

That discussion seemed to resolve to "we need to check to see if we are 
updating 2119 language" :-)

>
> So now my naive question is; do we care about 5245 with 5245bis soon 
> finished?

The same language is currently in 5245bis.

>
> I think we have two possible solutions.
>
> 1. Make dual-stack fairness reference only 5245bis. Make sure text in 
> both draft harmonise. They will cross reference each other and thus 
> needs to be published at the same time?

Would you expect ICEBis to normatively reference this? If so, that has 
implications about the PS/Informational/BCP decisions. If so, they would 
form a cluster in the RFC editor queue. Even if they were submitted at 
different times, they would be formally published more or less at the 
same time.

>
> 2. Explain why we are not braking the 5245 SHOULD and keep it as 
> informational . This is done by pointing out the appropriate text you 
> found in 6724.

The current text is misleading, in the way it explicitly says that 
following the SHOULD in 5245/5245bis leads to "unfair" prioritization. 
As written, it does seem to relax the SHOULD. Language clarifying that 
6724 allows application-specific choices would be helpful.

>
> And in either case: Is there an opportunity to make 5245 more clear in 
> 5245bis?
>
>
> Absolutely. It must also point out that the formulas described in 5245 
> section 4.1.2 have not changes so that the compatibility discussion in 
> section 5 of the dual-stack fairness draft is still valid.
>
>
> That of course leads to the bombshell question: We are already in the 
> process of updating 5245. Why isn’t _this_ draft part of 5245bis?
>
> I think the main motivation for that was to keep the ICEbis spec as 
> short as possible as there are some implementations that does not care 
> about the problem. For the implementations that do care, they should 
> read the draft and follow the recommendations.

I don't find that all that convincing. ICEbis talks about dual-stack 
stuff in several places, and makes that explicit statement about 
dual-stack behavior and 6724. A good part of the content of _this_ draft 
is spent describing things in ICE/ICEbis for context, and could probably 
be significantly reduced.

One possibility might be to move the procedure parts into ICEBis, and 
refer back to this draft for motivation and an explanation of why a 
happy eyeballs approach is useful. (Or maybe that could just go into an 
appendix of ICEbis.)

Now, I don't have a strong belief this needs to merge into ICEBis--I 
just want to make sure the working group has thought about the option. 
In particular, we should consider what makes things easier on the 
reader, not just what is easier from an IETF process perspective.

>
> Minor:
>
> - 1: The introduction jumps right to saying applications need to 
> deprioritize interfaces without saying what problem it's trying to 
> solve. An initial paragraph that says what goes wrong with current 
> implementations would be extremely helpful. It would also help to 
> define what is meant by "fairness" in this context. (I’m not sure 
> it's quite the same as the conventional use of the term.)
>
> How about:
>
>    In multihomed and IPv4/IPv6 dual-stack environments ICE [RFC5245]
>    would benefit by a fair distribution of its connectivity checks
>    across available interfaces or IP address types.  With a fair
>    distribution of the connectivity checks, excessive delays are 
> avoided
>    if a particular network path is broken or slow.  It would arguable 
> be
>    better to put the interfaces or address types know to the 
> application
>    last in the checklist.  However, the main motivation by ICE is to
>    make no assumptions regarding network topology, hence a fair
>    distribution of the connectivity checks is more appropriate.  If an
>    application operates in a well-known environment is can safely
>    override the recommendation given in this document.

That helps, but I still don't see s definition of what you mean by "fair 
distribution".

>
>
> - 2: Assuming this stays informational, it's not really using the 2119 
> keywords quite in the spirit of 2119. Personally, I don't think the 
> current 2119 usage (outside of text directly attributed to other 
> documents, which doesn't really count) adds much. I suggest removing 
> it.
>
> But if people are really attached to using 2119 language here, please 
> consider adjusting the boilerplate to say that, while this draft does 
> not include normative requirements, the keywords are used for the sake 
> of clarity.
>
>
> Agree. Removed from draft. And all capital SHOULD occurrences replaced 
> with should.

That works for me, assuming people choose to keep this as an 
informational.

>
> -3, 2nd paragraph:
>
> Does the working group believe that one can make reasonable inferences 
> from just the network type? Do you expect these to be configurable? 
> Statically defined in code? (Seems like there may be operational 
> considerations here.)
>
> The original intent with the text was to say; “If you think you know 
> better, please feel free to do as you please…”. But basing it just 
> on network type seems to be a bit to fragile.
>
> Updated text:
>   The application knowledge regarding the reliability of an interface
>    can also be based on simple metrics like previous connection 
> success/
>    failure rates or a more static model based on interface types like
>    wired, wireless, cellular, virtual, tunneled in conjunction with
>    other operational metrics.  This would require the application to
>    have the right permissions to obtain such operational metrics.

That helps, thanks.

>
>
> - 7.2: Can this be more specific about what implementations exist? The 
> boilerplate seems a bit heaviweight for something that pretty much 
> says “there are others" :-)
>
>
> The section has been in and out. Main use is to inform WG and AD that 
> there are others? Others have confirmed during WG meetings that they 
> do things similar to what is described in the draft (But sometimes 
> they have more operational knowledge and are able to override things 
> in the draft).
>
> Safe to remove this section now?

This sort of thing usually comes out at publication time, so it's 
probably fine for now.

>
>
> Editorial:
>
> - 4 , first paragraph: How long is long?  (Especially if you stick the 
> 2119 SHOULD).
>
> I think long can be dropped. IMHO intermingling of the address types 
> is a good thing if you want to be topology agnostic.
> The paragraph still have “values”  like many and small. I think 
> that is ok?
>
> New paragraph:
>    Candidates should be prioritized such that a sequence of candidates
>    belonging to the same address family will be intermingled with
>    candidates from an alternate IP family.  For example, promoting 
> IPv4
>    candidates in the presence of many IPv6 candidates such that an 
> IPv4
>    address candidate is always present after a small sequence of IPv6
>    candidates, i.e., reordering candidates such that both IPv6 and 
> IPv4
>    candidates get a fair chance during the connectivity check phase.
>    This makes ICE connectivity checks more responsive to broken path
>    failures of an address family.

WFM.

>
> - 5, last paragraph: Doesn’t this belong in the "Implementation 
> Status" section?
>
> The intent was to guide implementers to sample code. If that is moved 
> to Implementation Status that information will be lost when published 
> as an RFC.
>
> Previous versions had an appendix with the code examples. The WG felt 
> that that was a to strong encouragement to implement a specific 
> solution, this was something the WG did not want to do. Hence the 
> informational status of the draft.
>
> I am fine with removing it.

I don't necessarily object to keeping it, but keep in mind that RFCs 
live forever, and code repositories might not.

>
>
> - 7.1 and 7.2 titles: s/Starck/Stack
>
> Gahh.. Fixed even if removed later..
>
> - 7.1, "Level of Maturity": Are there words missing around "Tests"?
>
> Cut and paste error.
>
>
>
> Do you want me to post a new version of the draft with the changes. We 
> still need to resolve the 5245, 5245bis and 6724 problem. Simple 
> enough once we agree.

Revisions are cheap :-) I'd suggest updating with the known changes now, 
then dealing wtih the other stuff when we can.

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 May 2016 11:03:15 +0000

Hi,

I have not been very much involved the dualstack-fairness
work/discussions, so forgive me if the following issues have already been
discussed.

As the purpose of the draft is to ³make things work better², I see no
reason why we simply couldn¹t implement the change in 5245bis. I don¹t
think we need too much extra text for the justification, and it could e.g.
be put in an appendix as suggested.

Now, regarding the statement that ³some people don¹t care/need this², how
much will the technical change affect them? If you want to be compliant
with 5245bis, you are anyway going to have to do some changes in your code.

Regards,

Christer

On 03/05/16 20:25, "Ice on behalf of Ben Campbell" <[email-masked]
on behalf of [email-masked]> wrote:

>> next commentŠ)
>> Just for clarity I will summarise what I see as the key ³events²
>> the various scenarios. Think the ³consensus in the hallways² was
>>   to override an application or upper layer¹s explicit choice of a
>> process of updating 5245. Why isn¹t _this_ draft part of 5245bis?
>>
>> define what is meant by "fairness" in this context. (I¹m not sure
>> The original intent with the text was to say; ³If you think you know
>> better, please feel free to do as you pleaseŠ². But basing it just
>> says ³there are others" :-)
>>
>>
>> The paragraph still have ³values²  like many and small. I think
>> that is ok?
>>
>> New paragraph:
>> - 5, last paragraph: Doesn¹t this belong in the "Implementation
>> Status" section?
>>
>_______________________________________________
>Ice mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ice

---

From: Ari Keränen <[email-masked]>
Date: Sun, 22 May 2016 20:34:56 +0000

Hi,

Regarding the split to different drafts, our goal with the ICEbis work was to fix errors and make sure we have the right hooks and text for the extensions that we need. And we decided that everything else, such as new features/extra functionality, would go to different document(s). Of course the DS draft is a borderline case, but given how much material (e.g., the algorithm) there is, to me (chair hat off) separate document sounds still like a better idea.

But yes, the current text in ICEbis about RFC6724 needs to be updated and point to the dual-stack document. Having text there about the general procedure makes sense.

Regarding BCP or Informational for the DS draft status, I don't think we considered the BCP option. Now thinking about it, BCP seems reasonable option.

Cheers,
Ari

> On 20 May 2016, at 14:03, Christer Holmberg <[email-masked]> wrote:
> 
> 
> Hi,
>

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 23 May 2016 10:58:49 +0000

> On 22 May 2016, at 22:34, Ari Keränen <[email-masked]> wrote:
> 
> Hi,
> 

+1 BCP Seems like a better option. 

The current proposal for progressing this draft:
- Move from Informational to BCP
- ICEbis will have a normative reference to ICE-Dualstack fairness. (So this can potentially hold up ICEbis, but probably not)
- Text can be shortened a lot if we assume readers are more familiar with ICE and only reference the appropriate ICE sections. I prefer the current text as it saves readers familiar with ICE but without fresh memories of details some time looking up the appropriate ICE section. 
- Normative references to ICEbis instead of ICE. Work with ICEbis to remove current ambiguity of SHOULD wording regarding 6724 (Will hold publication of draft until ICEbis is complete). 

Not sure if this requires a new WGLC. The chairs will decide that.

.-.
Pål-Erik

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 23 May 2016 11:14:35 +0000

Hi,

>>Regarding the split to different drafts, our goal with the ICEbis work
>>was to fix errors and make sure we have the right hooks and text for the
>>extensions that we need. And we decided that everything else, such as
>>new features/extra functionality, would go to different document(s). Of
>>course the DS draft is a borderline case, but given how much material
>>(e.g., the algorithm) there is, to me (chair hat off) separate document
>>sounds still like a better idea.
>> 
>> But yes, the current text in ICEbis about RFC6724 needs to be updated
>>and point to the dual-stack document. Having text there about the
>>general procedure makes sense.
>> 
>> Regarding BCP or Informational for the DS draft status, I don't think
>>we considered the BCP option. Now thinking about it, BCP seems
>>reasonable option.
>> 
>
>- ICEbis will have a normative reference to ICE-Dualstack fairness. (So
>this can potentially hold up ICEbis, but probably not)

Just to verify: is it allowed to have a normative reference to a BCP?

>- Text can be shortened a lot if we assume readers are more familiar with
>ICE and only reference the appropriate ICE sections. I prefer the current
>text as it saves readers familiar with ICE but without fresh memories of
>details some time looking up the appropriate ICE section.

If we keep it as a separate draft, I personally have no strong opinion on
how much text is kept.

> 
>- Normative references to ICEbis instead of ICE.

Yes - this is something we should do in ALL new/ongoing work referencing
ICE (unless there are cases where, for some reason, we explicitly ned to
reference RFC 5246).

> Work with ICEbis to remove current ambiguity of SHOULD wording regarding
>6724 (Will hold publication of draft until ICEbis is complete).

Feel free to suggest text :)

Regards,

Christer

>>>>>(http://www.ietf.org/proceedings/92/minutes/minutes-92-mmusic#h.v0jtwu
>>>>>5re
>>>>> 90f)
>>>>> 
>>>>> 
>>>>><http://www.ietf.org/proceedings/92/minutes/minutes-92-mmusic#h.v0jtwu
>>>>>5re
>>>>> 90f>- 
>>>>>(http://www.ietf.org/proceedings/93/minutes/minutes-93-mmusic#h.34ilx3
>>>>>y4v
>>>>> kbd)
>>>> 
>>>>>http://www.ietf.org/proceedings/90/minutes/minutes-90-mmusic#h.6fijdpv
>>>>>ean
>>>>> aa
>>>>

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 23 May 2016 09:25:17 -0500

I'm okay with this approach in general. Some comments inline:

Thanks!

Ben.

On 23 May 2016, at 5:58, Pal Martinsen (palmarti) wrote:

>> Regarding the split to different drafts, our goal with the ICEbis 
>> work was to fix errors and make sure we have the right hooks and text 
>> for the extensions that we need. And we decided that everything else, 
>> such as new features/extra functionality, would go to different 
>> document(s). Of course the DS draft is a borderline case, but given 
>> how much material (e.g., the algorithm) there is, to me (chair hat 
>> off) separate document sounds still like a better idea.
>>

I think that makes sense, if we keep it separate from ICEBis. As an 
individual, I think merging it into ICEBis would be the best long-term 
choice, but as AD I'm ok with progressing things as is for "historical" 
reasons. (read: Because we've gotten this far separately, merging them 
would create a fair amount of re-work.) But do not be surprised if this 
comes up again during IESG review.

> - ICEbis will have a normative reference to ICE-Dualstack fairness. 
> (So this can potentially hold up ICEbis, but probably not)
> - Text can be shortened a lot if we assume readers are more familiar 
> with ICE and only reference the appropriate ICE sections. I prefer the 
> current text as it saves readers familiar with ICE but without fresh 
> memories of details some time looking up the appropriate ICE section.

The big issue here is, since ICEBis is still in play, do we expect the 
explanatory text to stay "current"? Otherwise, it's just a matter of 
making being clear that whatever explanatory material exists makes it 
clear that it is not authoritative.

I'll leave this to the authors an chairs to decide. My personal advice 
would be to keep some explanatory text, but shorten it quite a bit. It's 
reasonable to have enough to give a reader a sense of what is going on, 
but it's also reasonable to expect people to understand ICE to fully 
understand this.

> - Normative references to ICEbis instead of ICE. Work with ICEbis to 
> remove current ambiguity of SHOULD wording regarding 6724 (Will hold 
> publication of draft until ICEbis is complete).

+1

> Not sure if this requires a new WGLC. The chairs will decide that.

Things like changing to BCP, changing normative references, etc need to 
be confirmed with the working group. It might make sense to reconfirm 
the split draft approach, but I will leave that to the chairs to decide. 
I don't think these things need a full WGLC, but if that's the easiest 
way forward it doesn't hurt.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 23 May 2016 09:26:25 -0500

> Just to verify: is it allowed to have a normative reference to a BCP?

Yes, a BCP has the same status as a standards track RFC for the purposes 
of normative references.

Ben.