Happy Eyeballs: Success with Dual-Stack Hosts
draft-ietf-v6ops-happy-eyeballs-07

[Ballot discuss]
Updated to reflect discussion among the authors, WG chairs, and AppsDir reviewer.

Major Issue #1: Scope limited to TCP. The new text is good. Cleared.

Major Issue #2: Why Standards Track? Waiting on feedback from Pete Resnick.

Minor Issue #1: Preferred address family. The new text is good. Cleared.

Minor Issue #2: Where algorithm is meant to be implemented. Working toward consensus on new text. Waiting on feedback from authors.

Minor Issue #3: Description of implementation work. The new text is good. Cleared

Minor Issue #4: Use of cache for debugging. The new text is good. Cleared.

Minor Issue #5: Timing recommendations. The new text is good. Cleared.

Minor Issue #6: WEBSEC review? Not explicitly completed, but OK. Cleared.

Minor Issue #7: Caching of results. Some confusion about whether to mention caching in the example, or remove it altogether. Waiting on feedback from authors.

[Ballot discuss]
I would now like to DISCUSS why this document has been moved to Informational from Standards Track. As written, I think it is inappropriate for Informational.

[Ballot comment]
I really think this document should have had a co-author in the apps area. It is written exceedingly "thinly" and doesn't really understand some of the application implementation issues. That said, I still think it is valuable and worth publishing (and hopefully updating in the future). Though it is a bit this for the standards track as it is now, I see the potential to fill this in over time with more proscriptive information, and therefore I don't object to go it going on the standards track now in anticipation of that. Some issues to consider for this go-round:

3.1 - This has nothing to do with URIs. It is about hostnames. Hostnames used that don't appear in URIs have exactly the same issues.

4. - Though using SYN and ACK in the diagram is fine, I recommend using words like "connection attempt" in the descriptive text. SYN and ACK are probably not as familiar to application layer folks, and since this is aimed at them, it is likely better to use the application layer terminology. Furthermore, there is a performance/resource impact to making a "connection attempt" that an apps person will understand that they might not if it is understood as only an additional packet.

I agree with Stephen's concerns regarding "MUST cache". There are valid reasons to try v6 later even if v4 succeeds first, but those reasons must be carefully considered and understood. That sounds like a SHOULD.

4.1 - The first few paragraphs strike me as introductory material, not part of the alogirthm requirements.

4.2. - "SHOULD do so every 10 minutes" I think instead you mean "SHOULD do so no more frequently than every 10 minutes". It's perfectly fine to do so every 20 minutes, or once a day.

4.3. - DNA does not describe how applications (which are the ones who are going to implement Happy Eyeballs) are to be notified of these changes. Though I agree that a Happy Eyeballs app should be able to ask its host to do a DNA for it (or more to the point, get notifications from the host), that's an additional requirement on these apps and should be noted.

[Ballot comment]
I understand why improving IPv6 experience in dual stack deployments is
valuable to the IETF in promoting migration to IPv6. For that reason,
publication of this document may be beneficial and encourage
implementations to include more flexible selection algorithms such as
that described in this document. However, I don't see anything in this
document that impacts interworking, so I don't see why it is Standards
Track.

[Ballot discuss]
Two hopefully quick questions, not sure if the answers will lead to
changes or not: (I didn't see any change in -06 related to these
nor any response email so I'll hold the discuss for now. Sorry if
I've missed something.)

#1, p5, last para, says the client "MUST cache that information" but
doesn't say what information (the IP addresses, the DNS name) nor
for how long (DNS TTL? browser session?). Is it ok to not specify
this?

#2, section 4.3 says SHOULD re-initialise on a new connection. If I
have two interfaces (e.g. WiFi and GSM) and one of them is thrashing
up and down continually, are you saying that the happy eyeballs
state on the other interface SHOULD also be re-initialised or not?
Maybe s/host/interface/ or some other change would be better if
not, or make it clear that you do want state for both interfaces to
be re-initialised if that's the case.

[Ballot discuss]
The Apps Directorate review by Murray Kucherawy on 2011-11-26 raised two major technical issues and eight minor technical issues. These issues merit a response. The review can be found here:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03819.html

[Ballot discuss]
1) should thi sbe informational since it is now only a list of requirements?

2) 5.6 should say why the A6 should not be queried.

[Ballot comment]
- I agree with Wes' discuss

- p7 says there will be "less and less IPv4 traffic" but that
doesn't follow. E.g. absolute amounts of IPv4 traffic could still
increase even if IPv4 is decreasing proportional to IPv6. I think
you could lose that entire paragraph and the following one, which
only seem to be there to justify the "Thus," in the last para
of 4.1.

[Ballot discuss]
Two hopefully quick questions, not sure if the answers will lead to
changes or not:

#1, p5, last para, says the client "MUST cache that information" but
doesn't say what information (the IP addresses, the DNS name) nor
for how long (DNS TTL? browser session?). Is it ok to not specify
this?

#2, section 4.3 says SHOULD re-initialise on a new connection. If I
have two interfaces (e.g. WiFi and GSM) and one of them is thrashing
up and down continually, are you saying that the happy eyeballs
state on the other interface SHOULD also be re-initialised or not?
Maybe s/host/interface/ or some other change would be better if
not, or make it clear that you do want state for both interfaces to
be re-initialised if that's the case.

[Ballot comment]
It may be worth mentioning at some point that in the "race" between an IPv4 and IPv6 SYN that the IPv6 SYN can be at a disadvantage due to potential tunneling causing an even less efficient path to be taken than the one that the IPv4 packet takes.

[Ballot discuss]
This is good and important work, and I will change to "Yes", if one simple item can be addressed.  There's an implicit assumption that applications are using connection-oriented transport (e.g. TCP or SCTP), and there isn't clear discussion of whether the technique is applicable or not to applications that use connectionless transport (e.g. it would at least have different considerations for applications using a stateful stream of UDP packets versus those that only use a request-response message pattern and don't keep much state between transactions).

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Happy Eyeballs: Success with Dual-Stack Hosts) to Proposed Standard


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Happy Eyeballs: Success with Dual-Stack Hosts'
  as a Proposed Standard

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 2011-11-10. 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


  When the IPv4 server and path is working but the IPv6 server or IPv6
  path is down, a dual-stack client application experiences significant
  connection delay compared to an IPv4-only client.  This is
  undesirable because it causes the dual-stack client to have a worse
  user experience.  This document specifies requirements for algorithms
  that reduce this delay, and provides an example algorithm.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-happy-eyeballs/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-happy-eyeballs/


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

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The document shepherd is Fred Baker. Yes, I believe that it is ready for IESG consideration.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has had extensive review, prototyping, and multiple implementations in different browsers. I think the problem and the proposed solution are well understood.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

I would not object to a security or operational review. That said, I don't think that the procedure carries significant security or operational issues.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

We are not aware of issues, IPR or otherwise.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is wide consensus behind this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the
Internet-Drafts Checklist
and
http://tools.ietf.org/tools/idnits/
). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

idnits raises two issues:
** Downref: Normative reference to an Informational RFC: RFC 3363

== Outdated reference: A later version (-06) exists of
draft-ietf-websec-origin-04

The latter is due to the fact that draft-ietf-websec-origin has been updated. The RFC 3363 issue relates to the representation of an address in the draft. That can be moved to "informative" if the IESG asks (I asked and it didn't happen :-).


(1.h) Has the document split its references into normative and
informative?

Yes

Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

No

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

Yes

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are none

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

When the IPv4 server and path is working but the IPv6 server or IPv6
path is down, a dual-stack client application experiences significant
connection delay compared to an IPv4-only client. This is
undesirable because it causes the dual-stack client to have a worse
user experience. This document specifies requirements for algorithms
that reduce this delay, and provides an example algorithm.

Working Group Summary

v6ops considered this carefully, and tested various possible implementations of the solution.

Document Quality

The document appears to be of high quality per the numerous reviews received.