Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE)
draft-ietf-ice-dualstack-fairness-07

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-ice-dualstack-fairness-07.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ben@nostrum.com, ari.keranen@ericsson.com, draft-ietf-ice-dualstack-fairness@ietf.org, ice-chairs@ietf.org, ice@ietf.org, "Ari Keranen"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ICE Multihomed and IPv4/IPv6 Dual Stack Guidelines) to Best Current Practice RFC


The IESG has received a request from the Interactive Connectivity
Establishment WG (ice) to consider the following document:
- 'ICE Multihomed and IPv4/IPv6 Dual Stack Guidelines'
  as a BCP.

This document was previously last called (twice! )  with an
incorrect intended  status. The correct intended status is BCP. 
Please focus comments on that change.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-12-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document provides guidelines on how to make Interactive
  Connectivity Establishment (ICE) conclude faster in multihomed and
  IPv4/IPv6 dual-stack scenarios where broken paths exist.  The
  provided guidelines are backwards compatible with the original ICE
  specification.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/ballot/


No IPR declarations have been submitted directly on this I-D.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-ice-dualstack-fairness-07.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ben@nostrum.com, ari.keranen@ericsson.com, draft-ietf-ice-dualstack-fairness@ietf.org, ice-chairs@ietf.org, ice@ietf.org, "Ari Keranen"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ICE Multihomed and IPv4/IPv6 Dual Stack Guidelines) to Informational RFC


The IESG has received a request from the Interactive Connectivity
Establishment WG (ice) to consider the following document:
- 'ICE Multihomed and IPv4/IPv6 Dual Stack Guidelines'
  as Informational RFC

This document was previously last called with an incorrect intended
status. The correct intended status is Informational. Please focus
comments on that change.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-11-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document provides guidelines on how to make Interactive
  Connectivity Establishment (ICE) conclude faster in multihomed and
  IPv4/IPv6 dual-stack scenarios where broken paths exist.  The
  provided guidelines are backwards compatible with the original ICE
  specification.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/ballot/


No IPR declarations have been submitted directly on this I-D.

[Ballot comment]
Thanks for addressing my comments and also not talking about fairness anymore. There are some more concrete recommendations now but some are still vague.

I would still like to proposed the following addition to the intro:

OLD:
"To avoid such user noticeable delays when either IPv6 or IPv4 path is
  broken or excessively slow, this specification encourages
  intermingling the different address families when connectivity checks
  are performed.  This will lead to more sustained dual-stack IPv4/IPv6
  deployment as users will no longer have an incentive to disable IPv6.
  The cost is a small penalty to the address type that otherwise would
  have been prioritized."

NEW:
"To avoid user noticeable delays when either IPv6 or IPv4 path is
  broken or excessively slow, this specification encourages
  intermingling the different address families when connectivity checks
  are performed.  This will lead to more sustained dual-stack IPv4/IPv6
  deployment as users will no longer have an incentive to disable IPv6.
  The cost is a small penalty to the address type that otherwise would
  have been prioritized. Further this document recommends to keep
  track of previous known connectivity problem and assign a lower
  priority to those addresses."

Maybe even add:
"Tracking connectivity is a question on its own and out of scope for
  this document."

[Ballot comment]
Thanks for addressing my DISCUSS.

Previous COMMENT:

= Section 3 =

"If the agent has access to
  information about the physical network it is connected to (Like SSID
  in a WiFi Network) this can be used as information regarding how that
  network interface should be prioritized at this point in time."

I think this needs further elaboration, as it's not obvious how knowledge of the SSID correlates to knowledge of the stability of the network.

"Candidates from an 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."

All three of these sentences say more or less the same thing, so two of them could be dropped.

= Section 8 =

Doesn't following the recommendations in Section 3 potentially leak information to a remote peer about the quality of a local peer's connectivity on different interfaces? That is, if the remote peer maintains some state about past ICE interactions, would it be able to detect a change of priority that could indicate a change in connectivity quality? If so, this seems worth mentioning.

[Ballot discuss]
* Section 4

I am trying to see if there is any background for the following statement

"It is worth noting that the timing recommendations in [RFC6555] are not optimal for ICE usage."

Why is it not optimal? Do you want smaller or larger timings? Some explanations here would be good. Additionally, it might be worthwhile for this document to provide alternate timing recommendations that *are* optimal.

[Ballot comment]
* Agree with Alissa's DISCUSS point. I ran into the same circular reference
* Agree with Mirja's comment about fairness being the wrong term to use

[Ballot discuss]
The draft is intended as a BCP, but we ran the IETF Last Call as an informational. This is entirely my fault. I'm entering a "process" discuss to hold approval until we can re-run the last call. Let's complete resolve any other issues that come up in IESG evaluation, then I will re-run an abbreviated last call focusing on the status change.

[Ballot discuss]
= Section 4 =

"However, modifying the check list
  directly can lead to uncoordinated local and remote check lists that
  result in ICE taking longer to complete or in the worst case scenario
  fail.  The best approach is to modify the formula for calculating the
  candidate priority value described in ICE [I-D.ietf-ice-rfc5245bis]
  section "4.1.2.1 Recommended Formula"."

ICEbis section 4.1.2.1 then says:

"If a host is
  multihomed because it is dual-stack, the local preference should be
  set according to the current best practice described in
  [I-D.ietf-ice-dualstack-fairness]."

So, there is a circular reference, and nowhere is it specified how the formula should actually change. I think it's fine to put this in ICEbis, but if this draft is going to reference it then it actually needs to be specified there.

Alternatively, if this text is meant to reference the discussion further down in Section 5, I wouldn't call that modifying the formula, but rather providing guidance about how to set local preferences within the formula.

[Ballot comment]
= Section 3 =

"If the agent has access to
  information about the physical network it is connected to (Like SSID
  in a WiFi Network) this can be used as information regarding how that
  network interface should be prioritized at this point in time."

I think this needs further elaboration, as it's not obvious how knowledge of the SSID correlates to knowledge of the stability of the network.

"Candidates from an 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."

All three of these sentences say more or less the same thing, so two of them could be dropped.

= Section 8 =

Doesn't following the recommendations in Section 3 potentially leak information to a remote peer about the quality of a local peer's connectivity on different interfaces? That is, if the remote peer maintains some state about past ICE interactions, would it be able to detect a change of priority that could indicate a change in connectivity quality? If so, this seems worth mentioning.

[Ballot discuss]
This should be very easy to resolve:  The Intended RFC status on the datatracker, the Last Call, Shepherd write-up, etc. says Informational, but the header in the document says Best Current Practice.  Please update.

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

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?

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

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

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

[Ballot comment]
Thanks for doing this work.

The document thinks it's going for Best Current Practice, but the shepherd write-up and datatracker think it's going for Informational. It would be good for that to match ...

I'm a little confused by

  These recommendations are backward compatible with a standard ICE
  implementation.  The resulting local and remote checklist will still
  be synchronized.  The introduced fairness might be better, but not
  worse than what exists today
 
Is the point that the introduced fairness
- might be better, or
- might be the same as, but
- won't be worse?

If so, that wasn't clear to me on first (or second) reading.

(Nit: missing period at the end of "what exists today")

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ice-dualstack-fairness-03.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ben@nostrum.com, ari.keranen@ericsson.com, draft-ietf-ice-dualstack-fairness@ietf.org, ice-chairs@ietf.org, ice@ietf.org, "Ari Keranen"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ICE Multihomed and IPv4/IPv6 Dual Stack Fairness) to Informational RFC


The IESG has received a request from the Interactive Connectivity
Establishment WG (ice) to consider the following document:
- 'ICE Multihomed and IPv4/IPv6 Dual Stack Fairness'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-07-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document provides guidelines on how to make Interactive
  Connectivity Establishment (ICE) conclude faster in multihomed and
  IPv4/IPv6 dual-stack scenarios where broken paths exist.  The
  provided guidelines are backwards compatible with the original ICE
  specification.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/ballot/


No IPR declarations have been submitted directly on this I-D.

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

1. Summary

The document shepherd is Ari Keränen. The responsible Area Director is Ben Campbell.

This document provides guidelines on how to make Interactive Connectivity Establishment (ICE) conclude faster in multihomed and IPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backwards compatible with the original ICE specification.

2. Review and Consensus

The document has been worked both at MMUSIC and ICE working groups since IETF #86 and the document has received multiple reviews over time. Overall the mechanism is simple but details of the suggested algorithm were discussed and updated throughout the process. General concerns on behaviour with unreliable tunnelling mechanisms were raised but no specific issues were discovered and the draft was updated to note this issue in general. The final version received four reviews. Reviews from WGLC resulted only in editorial changes. There are two implementations of the mechanism.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other Points

While the document uses RFC2119 text to describe the mechanism, there was WG consensus to publish this as Informational document. The reference to obsoleted RFC 3484 is intentional as it is part of the discussion of evolution of prioritisation rules.