Subject: [v6ops] I-D ACTION:draft-ietf-v6ops-happy-eyeballs-03.txt

From: [email-masked]
Date: Mon, 11 Jul 2011 09:15:03 -0700

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

    Title         : Happy Eyeballs:  Success with Dual-Stack Hosts

    Author(s)     : D. Wing, et al
    Filename      : draft-ietf-v6ops-happy-eyeballs-03.txt
    Pages         : 13
    Date          : 2011-07-11
    
   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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-happy-eyeballs-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 11 Jul 2011 21:06:20 +0200

I like this approach. By now, my own HE algorithm is quite complex and it
would probably take a long time to get any kind of consensus about what
algorithm to use. Maybe later we could have a separate BCP that outlines
how to construct a HE implementation.

I'll start with some comments on specific parts of the draft and add some
suggestions for other issues that could/should be addressed.

Section 4.1

In my opinion the MUST is too strong. I think a SHOULD is more than enough.
But more importantly, Section 4.2 qualifies that MUST. I think that either
4.1 should contain a description of when MUST can be violated or it should
explicitly forward reference 4.2. In my opinion it is important that
requirements are as self-contained as possible.

Section 4.2

In think that Section 4.2 should explain what 'failed' means. Obviously,
if a protocol doesn't work at all, it should be considered failed. But I think
that in many cases, a tunnel that always adds 200 ms latency can be considered
as failing as well.

(my own algorithm just connects to whatever works best, without trying to
declare something as failed).

Section 5.5

I quickly read the (by now expired) draft on Same Origin Policy and I didn't
find anything that directly deal with IP addresses. 

If it were, then any setup that use a proxy would be in deep trouble.

I think that 'origin' in this context is a domain, not a specific address.
But I could be wrong.

Suggestions

1)

Playing with my own HE implementation I arrived a the following prototype for
the library function that provides it:

int tcp_connect_to_name(char *hostname, char *portname, int *gai_errp,
        struct timeval *tv);

I think application portability will be enhanced if HE implementations provide
similar features. There is also no need for OS implementors to all reinvent
the wheel.

2)

In practice, a DNS RR set may contain more than just one IPv4 and one IPv6
address. It may be a good idea to add some discussion about this. 

3)

In practice, local IPv6 connections may still work while the link to the
outside world is broken. What does 'failed' mean in this context?

4) 

What happens if I take the same algorithm as Google used in Chrome but I
set the timer to 30 ms instead of 300? Is that considered an acceptable HE
implementation according to this draft?

5)

This draft sometimes talks about an entire address family (for example
Section 4.2) but in other places (Section 4) it's about addresses for an
individual host. I think this should be make more clear in Sections 4.1 and
4.2.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Jul 2011 11:29:49 +1000

> similar features. There is also no need for OS implementors to all reinvent

Whereas mine is:

	 int connect_to_host(struct addrinfo *res0);

> address. It may be a good idea to add some discussion about this. 

Which is one of the reasons I keep saying that this isn't a IPv4/IPv6 issue
but a multi-homed server issue.
 
> outside world is broken. What does 'failed' mean in this context?

Again this is one of the reasons I keep saying that this isn't a IPv4/IPv6
issue but a multi-homed server issue.
 
> implementation according to this draft?

I can't see why not.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 21 Jul 2011 19:17:08 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Philip Homburg
> Sent: Monday, July 11, 2011 12:06 PM
> To: [email-masked]
> Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-happy-eyeballs-03.txt
> 
> I like this approach.

Thanks.

Sorry I have not summarized the changes to the list -- so thanks for 
commenting proactively.

> By now, my own HE algorithm is quite complex and
> it

You're referring to:

   Happy Eyeballs implementations MUST follow the host's address
   preference policy or, if that policy is unknown, implementations MUST
   prefer IPv6 over IPv4.

      Justification:  This reduces load on stateful IPv4 middleboxes
      (NAT and firewalls) and reduces IPv4 address sharing contention.

and I guess you're referring to that first MUST ("MUST follow the host's
address preference policy").

The qualification in 4.2 is really around implementations that maintain
state -- which I see I never actually said clearly in the I-D itself.
For example, the existing implementation in Chrome and Firefox doesn't
involve section 4.2 at all, because they don't remember if IPv6 has
always failed (except for their same origin policy).

As for MUST versus SHOULD, how is this:

        A Happy Eyeballs implementations MUST follow the host's
        address preference policy, unless the conditions
        in Section 4.2 apply).  If the host's policy is unknown or 
        not attainable, implementations MUST prefer IPv6 over IPv4.

I clarified 4.2 to better describe the implementation as stateful
(that is, the implementation notices that IPv6 is always failing).

> Section 4.2
> 
> In think that Section 4.2 should explain what 'failed' means.

Is this sufficient?

        <t>After making a connection attempt on the preferred address 
        family (e.g., IPv6), and failing to establish a connection
        within a certain time period, a Happy Eyeballs implementation
        will decide to initiate a second connection attempt using the
        other address family (e.g., IPv4).</t>

> Obviously,
> (my own algorithm just connects to whatever works best, without trying
> to declare something as failed).

I would classify the Chrome and Firefox algorithms as also connecting
to what 'works best', giving IPv6 a ~200ms head start.

> find anything that directly deal with IP addresses.

The Wiki page is a little better, and explains that there is no
canonical definition of Same Origin Policy.  A better reference
might be "to avoid DNS rebinding attacks", which is what really
encourages web browsers to sandbox their traffic to the same IP
address without regard to DNS TTLs or anything else.   But, I
imagine that could be considered part of the "same origin policy".

I'm not a browser person, so guidance for a better citation is
certainly welcome.

> similar features. There is also no need for OS implementors to all

Mark Andrews had a different prototype.  I don't have any preference,
of course.  But I want to finish this I-D.  

> address. It may be a good idea to add some discussion about this.

<section title="A and AAAA Resource Records">
<t>It is possible that an DNS query for an A or AAAA resource
record will return more than one A or AAAA address.  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, the next address SHOULD be the IPv4 address.</t>

<t>This means that a Happy Eyeballs implementation will not
try other IPv6 addresses that are returned; effecitively, the
Happy Eyeballs implementation will behave as if only one 
address was returned.</t>
</section>

> outside world is broken. What does 'failed' mean in this context?

There are two broad categories of H.E. algorithms:

  1. non-stateful algorithms, which don't remember how previous
     connections were successful or unsuccessful.   The implementations
     in Chrome and Firefox are of this type.

  2. stateful algorithms, which is what draft-ietf-v6ops-happy-eyeballs
     described previously.  This was the manipulation of the "P" variable
     in the previous version of draft-ietf-v6ops-happy-eyeballs.

For (1), failure doesn't mean anything -- it doesn't affect subsequent
connections.

For (2), I have tweaked Section 4.2 to more clearly explain what
happens with failures.  Specifically, failures to connect to the
preferred address family (e.g., IPv6) can cause the algorithm to
learn that failure always occurs and to prefer IPv4.

Text currently reads:

        <t>Some Happy Eyeballs algorithms will be stateful -- that is,
        the algorithm will remember that IPv6 always fails, or that IPv6
        to certain prefixes always fails, and so on.  This section
        describes such algorithms.</t>

        <t>After making a connection attempt on the preferred address 
        family (e.g., IPv6), and failing to establish a connection
        within a certain time period, a Happy Eyeballs implementation
        will decide to initiate a second connection attempt using the
        other address family (e.g., IPv4).</t>

        <t>Such an implementation
        MAY make subsequent connection attempts 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. It is RECOMMENDED
        that implementations try the preferred address family at least every
        10 minutes. Note: this can be achieved by connecting to both address
        families at the same time, which does not significantly harm the
        application's connection setup time for the successful address
family.
        If connections using the preferred address family are successful,
the
        preferred address family SHOULD be used for subsequent
        connections.</t>

> implementation according to this draft?

Yes.  The normative text does not define the duration of the delay
between trying IPv6 and trying IPv4.  In fact, you could try them both
at the same time -- so long as the IPv6 one is "preferred" (by some
definition of preferred), and the network is not thrashed with
simultaneous connections.  Complex algorithms, such as what we
had earlier in draft-ietf-v6ops-happy-eyeballs, achieve this.  As
do simple algorithms such as what is in Chrome and Firefox.

> individual host. I think this should be make more clear in Sections 4.1
> and 4.2.

I don't know how to best fix all of that, especially if we consider
that a host could have an IPv4-mapped IPv6 address in DNS (ugly, but 
it happens) as well as a real IPv4 address.  That is, I don't know
if it's best to talk about "address family" or "address" throughout
the document.

-d

> 
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Philip Homburg <[email-masked]>
Date: Sun, 24 Jul 2011 12:00:38 +0200

>address preference policy").

Yes.

>(that is, the implementation notices that IPv6 is always failing).

Yes, that is fine.

>        other address family (e.g., IPv4).</t>

In that case, I think you need some text about what 'a certain time period'
is. For example, that an implementation may have a static value, or that
it may determine this value dynamically by observing IPv4 and IPv6 connect
times.

>to what 'works best', giving IPv6 a ~200ms head start.

I don't think this particular algorithm connects to what works best. It just
limits the damage that can be done by a failing IPv6 link to 200ms of
additional latency.

>I'm not a browser person, so guidance for a better citation is

I'd say that unless there is a standard that defines the Same Origin Policy,
Happy Eyeballs should not have an normative text regarding it.

Of course, it doesn't do any harm to point out to readers that Happy Eyeballs
may conclict with this policy.

I guess that in practice, if you already know which address to are going to
connect to (because the policy only allows you to connect to the same address
as before) there will be no need for HE anyhow.

>of course.  But I want to finish this I-D.  

Easy way forward is to list both for the time being and try to get people to
express a preference. 

I don't care so much which one gets picked, as long as we do what we can to
get one function standardized across platforms.

>address was returned.</t>

This is not good. Eventually, a host has to try all addresses in a RR set.

So after the first IPv6 address and the first IPv4 address it has to try
all other addresses, the order doesn't really matter, so the order returned by
getaddrinfo is probably best.

>        preferred address family SHOULD be used for subsequent

I guess that if an implementation notices that some (local) connections 
succeed but others don't, it can violate the SHOULD.

>do simple algorithms such as what is in Chrome and Firefox.

I don't think it would good idea if a popular product would start with IPv6
and then connects to IPv4 10ms later. That effectively double the connect
load on content, keep a huge load on any kind of CGN, and would effectively
make it impossible to phase out IPv4 because there will all be a huge number of 
connects over IPv4.

So I think that ideally, the document should give some performance
requirements. I.e. a HE implementation should connect to just one address in
over xx% of the cases, with xx close to 100.

That may not be feasable. So some text that the implementor of HE should ensure
that the parameters used are conservative enough that in most cases only one
address is connected to. Or something like that.

>if it's best to talk about "address family" or "address" throughout

Ultimately, the connect happens over IPv4 or IPv6. So given the level of
detail in the draft, address family (or maybe protocol) would be best,
except where you talk about individual addresses returned by getaddrinfo,
there it would an address that belong to a certain address family.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Jul 2011 14:03:04 -0400

> From: [email-masked] [mailto:pch-b2B3A6689@u-
> 1.phicoh.com] On Behalf Of Philip Homburg
> Sent: Sunday, July 24, 2011 6:01 AM
> To: Dan Wing
> Cc: [email-masked]
> >> if a protocol doesn't work at all, it should be considered failed.
> But
> >> I think

Agreed that some history ("state") of past success/failure would be helpful
to predict future success/failure, which would achieve something closer
to "what works best".

> >> Section 5.5
> >>
> >> I quickly read the (by now expired) draft on Same Origin Policy and
> I
> >> didn't

Sure, but Same Origin Policy only affects subsequent connections to a 
host -- not the first connection).  Optimizing that first connection
to a host is critical and what H.E. is primarily concerned with 
optimizing.

> >> I think application portability will be enhanced if HE
> implementations
> >> provide
> I don't care so much which one gets picked, as long as we do what we
> can to get one function standardized across platforms.

With the OSX Lion implementation, which affects both getaddrinfo()
[to reorder responses based on speed of previous IPv6 / IPv4 
connections] and the OSX-specific libraries, 
http://www.ietf.org/mail-archive/web/v6ops/current/msg09805.html,
I am even more reluctant to try to document One Algorithm To Rule
Them All.

> >> 2)
> >>
> >> In practice, a DNS RR set may contain more than just one IPv4 and
> one
> >> IPv6

Thanks.  Adjusted to read:

<t>If that fails to connect after a certain time (see <xref
target="timeout"></xref>), a Happy 
Eyeballs implementation SHOULD try the other addresses
returned; the order of these connection attempts is not
important.</t>

Yes.  

I don't want to get into all the reasons to violate the SHOULD; that
can become too restrictive (if we don't list all the reasons to violate
the SHOULD).

> >> 4)
> >>
> >> What happens if I take the same algorithm as Google used in Chrome
> but
> >> I
> >> set the timer to 30 ms instead of 300? Is that considered an
> acceptable
> >> HE

How is this:

<section anchor="timeout" title="Connection time out">
<t>The primary purpose of Happy Eyeballs is to reduce the wait time
for a dual stack connection to complete, especially when the IPv6 path
is broken and IPv6 is preferred.  Aggressive time outs (on the order
of tens of milliseconds) achieve this goal, but at the cost of network
traffic.  This network traffic may be billable on certain networks,
will create state on some middleboxes (e.g., firewalls, IDS, NAT), and
will consume ports if IPv4 addresses are shared.  For these reasons,
it is RECOMMENDED that connection attempts be paced to give
connections a chance to complete.  It is RECOMMENDED that connections
attempts be paced 150-250ms apart.  Stateful algorithms are expected
to be more aggressive (that is, make connection attempts closer
together), as stateful algorithms maintain an estimate of the expected
connection completion time.</t>
</section>

> >> Section 4.2) but in other places (Section 4) it's about addresses
> for
> >> an

Let's take that offline.

-d

---

From: Scott Brim <[email-masked]>
Date: Mon, 25 Jul 2011 14:09:45 -0400

> can become too restrictive (if we don't list all the reasons to violate

Typically this is done by listing examples of _classes_ of issues, so
that the implementor at least knows the kinds of situations where
violation might be reasonable.

It's good to justify SHOULDs because humans are such a varied lot.
Some vendors ignore all SHOULDs and implement only MUSTs, while others
implement all.  Some customers take SHOULDs as MUSTs and insist that a
vendor must implement them even if they can't use them, and so on.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Jul 2011 14:43:41 -0400

> From: Scott Brim [mailto:[email-masked]]
> Sent: Monday, July 25, 2011 2:10 PM
> To: Dan Wing
> Cc: Philip Homburg; [email-masked]

Good point.  How is this:

        If connections using the preferred address family are successful,
the
        preferred address family SHOULD be used for subsequent
        connections.  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).

-d