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

From: "Ben Campbell" <[email-masked]>
Date: Tue, 19 Apr 2016 01:36:25 -0500

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

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.

And in either case: Is there an opportunity to make 5245 more clear in 
5245bis?

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?

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

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

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

- 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" :-)

Editorial:

- 4 , first paragraph: How long is long?  (Especially if you stick the 
2119 SHOULD).

- 5, last paragraph: Doesn't this belong in the "Implementation Status" 
section?

- 7.1 and 7.2 titles: s/Starck/Stack

- 7.1, "Level of Maturity": Are there words missing around "Tests"?

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 19 Apr 2016 11:37:15 +0000

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)

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:

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

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

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?

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.

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.

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.

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

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

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

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.

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

Gahh.. Fixed even if removed later..

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.

.-.
Pål-Erik