Subject: [v6ops] comments on draft-ietf-v6ops-happy-eyeballs-04

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Fri, 23 Sep 2011 23:28:25 +0300

Hi,

Regarding the http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-04 draft, i wanted to make some comments.
This is my first try, so please try to be gentle with the answers  :-[

4
> The basic idea is depicted in the following diagram:
>
>             DNS Server                  Client                  Server
>                 |                          |                       |
>           1.    |<--www.example.com A?-----|                       |
>           2.    |<--www.example.com AAAA?--|                       |
>           3.    |---192.0.2.1------------->|                       |
>           4.    |---2001:db8::1----------->|                       |
>           5.    |                          |                       |
>           6.    |                          |==TCP SYN, IPv6===>X   |
>           7.    |                          |--TCP SYN, IPv4------->|
>           8.    |                          |<-TCP SYN+ACK, IPv4----|
>           9.    |                          |--TCP ACK, IPv4------->|
>          10.    |                          |==TCP SYN, IPv6===>X   |
>
>                 Figure 2: Happy Eyeballs flow 1, IPv6 broken
>
>     In the diagram above, the client sends two TCP SYNs at the same time
>     over IPv6 (6) and IPv4 (7).  In the diagram, the IPv6 path is broken
>     but has little impact to the user because there is no long delay
>     before using IPv4.  The IPv6 path is retried until the application
>     gives up (10).
Regarding the last sentence, why keep on trying the IPv6 when IPv4 has already been successful?

4.1
> If a Happy Eyeballs implementation treats IPv6 and IPv4
>     equally by connecting to whichever address family is fastest, it will
>     contribute to load on IPv4.

The above assumes IPv4 is faster than IPv6.
Although this is not always true (i tend to be optimistic, although i know it's difficult to find such examples), i believe a note should be added somewhere, explaining the assumption.

> This usually means giving
>     preferring IPv6 over IPv4, although that preference can be over-
>     ridden by user configuration or by network configuration

This should probably be written as:

This usually means giving*preference to*  IPv6 over IPv4, although that preference can be over-
    ridden by user configuration or by network configuration

Also, in various parts of 4.1 the phrase "can only utilize IPv4" can be re-written as "can utilize only IPv4", in order to move the focus of "only" from "utilize" to "IPv4".

4.2
>     After making a connection attempt on the preferred address family
>     (e.g., IPv6), and failing to establish a connection within a certain
>     time period (seeSection 5.7  <http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-04#section-5.7>), a Happy Eyeballs implementation will
>     decide to initiate a second connection attempt using the same address
>     family or the other address family.

If i understand correctly, the same address family will be retried only if the other other address family hasn't responded too. If that is the case, maybe it should be clarified.
On the other hand, if the other address family has responded, what is the reason of immediately retrying the address family that failed?

>      Such an implementation MAY make subsequent connection attempts (to
>     the same host or to other hosts) on the successful address family
>     (e.g., IPv4).  Such an implementation MUST occasionally make
>     connection attempts using the host's preferred address family, as it
>     may have become functional again, and is RECOMMENDED to do so every
>     10 minutes.  Implementation note:  this can be achieved by attempting
>     to connect to both address families at the same time every 10
>     minutes, which does not significantly harm the application's
>     connection setup time.  If connections using the preferred address
>     family are again successful, the preferred address family SHOULD be
>     used for subsequent connections.

The above paragraph is a little bit confusing to me.

First there is a MUST in order to use the host's preferred address family for connections (occasionally)
Then there is a SHOULD in order to use the host's preferred address family for (subsequent) connections

If MUST is there due to RFC3484, shouldn't it also be there in the second case?

> Because this implementation is
>     stateful, it MAY track connection success (or failure) based on IPv6
>     or IPv4 prefix (e.g., connections to the same prefix assigned to the
>     interface are successful whereas connections to other prefixes are
>     failing).

The above is not very clear to me. Especially the part into the parentheses.
Where does the term "same prefix assign to the interface" refer to?
"assign to the interface" makes me think it's the source prefix,
while "connections to" makes me think it's the destination prefix that needs to be tracked.

5.5
> It is possible that an DNS query for an A or AAAA resource record
>     will return more than one A or AAAA address.

Replace "an DNS query" with "a DNS query"?

> When this occurs, it is
>     RECOMMENDED that a Happy Eyeballs implementation order the responses
>     following the host's address preference policy and then try the first
>     address.  If that fails after a certain time (seeSection 5.7  <http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-04#section-5.7>), the
>     next address SHOULD be the IPv4 address.

I guess the IPv4 address SHOULD be the*first*IPv4 address.

-- 
Tassos