Subject: Re: [v6ops] Happy Eyeballs v2

From: 神明達哉 <[email-masked]>
Date: Mon, 1 May 2017 11:44:14 -0700

At Mon, 10 Apr 2017 10:43:45 -0700,
David Schinazi <[email-masked]> wrote:

> We've updated our "Update to Happy Eyeballs" document to address feedback received so far:
> https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-00 <https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-00>

> Thanks to everyone who sent feedback, and please let us know if this
> addresses yours.

My question (https://www.ietf.org/mail-archive/web/v6ops/current/msg25780.html)
is addressed with a reference to DNS-PUSH.  Thanks for that.

The following are my comments on the new version:

- general: in my understanding one of the biggest changes from RFC6555
  is the introduction of asynchronous DNS resolution.  And, also in my
  understanding, the overall wg feedback so far is that while it's
  nice to have it's too strong to say it's this is *the* (using
  MUST/MUST NOT) way to implement the technique called "Happy
  Eyeballs".  If this observation is accurate, the current text seems
  to be too radical.  While I personally don't have a strong opinion,
  I suspect this document will have to
  - get a wg consensus on its strong requirement, or
  - weaken the claim (not to say "obsolete RFC6555" and avoid
  MUST/MUST NOT)

- abstract: this doesn't talk much about asynchronous DNS resolution
  explicitly (maybe it's intended to be part of "algorithms that
  reduce this user-visible delay", but it's quite indirect).  As it's
  a major update, I think the abstract should clearly state it.

- Section 3

   Implementations MUST NOT wait for both families of answers to return
   before attempting connection establishment.

  See the above general comment.  This seems to be one of the too
  strong statements in this doc.

- Section 3

   The RECOMMENDED value for the Resolution Delay is 50 milliseconds.

  I'd suggest providing rationale for the choice of this value.

- Section 4

   [...]  If the client keeps track of which
   addresses it has used in the past, it SHOULD add another destination
   address selection rule between the RTT rule and rule 9, which prefers
   used addresses over unused ones.

  This can read as if once a destination address is known to work and
  is used other addresses will never be used as long as the chosen
  address is usable.  Is that the intent?

- Section 4

   Next, the client SHOULD modify the ordered list to interleave address
   families.  Whichever address family is first in the list should be
   followed by an address of the other address family;

  It's not clear to me whether this applies only to the first IPv6
  address and the first IPv4 address in the list, or any "pair" of
  IPv6/IPv4 addresses in the list.

- Section 5

   the "Connection Attempt Delay" SHOULD NOT such an aggressive backoff,
   as it would harm user experience.

  (editorial) it looks like a verb is missing after "SHOULD NOT".

--
JINMEI, Tatuya