Re: [v6ops] Measuring the Effectiveness of Happy Eyeballs

["Tony Hain" <[e-mail]>]

Dan Wing wrote:
> On Jul 4, 2013, at 6:02 AM, "Bajpai, Vaibhav"
<[e-mail]>
> wrote:
> 
> > Hello,
> >
> > I would like to request a 10-minute presentation slot at the upcoming
> > IETF 87 to present my PhD work:
> >
> > Title:		 Measuring the Effectiveness of Happy Eyeballs
> > Authors:	 Vaibhav Bajpai and Jürgen Schönwälder
> > URL:             http://tools.ietf.org/html/draft-bajpai-happy-00
> >
> > Abstract:
> >
> >  The IETF has developed solutions that promote a healthy IPv4 and IPv6
> > co-existence.  The happy eyeballs algorithm for instance, provides
> > recommendations to application developers to help prevent bad user
> > experience in situations where IPv6 connectivity is broken.  This
> > document describes a metric used to measure the effectiveness of the
> > happy eyeballs algorithm.  The insights uncovered by analysing the
> > data from multiple locations is discussed.
> 
> I noticed when this was published and presented earlier at
> https://ripe66.ripe.net/presentations/263-ripe66-happy-slides.pdf.  It's
nice
> to see it published as an Internet Draft, but disappointing that the
underlying
> Effective Measurement is testing something other than Happy Eyeballs.

It doesn't even acknowledge that the target nodes differ. DNS resolution of
a name does not tell you anything about deployed topology.

> 
> Happy Eyeballs is doing what it was designed to do -- provide a good user
> experience when the IPv6 (or IPv4) path is down.  However, draft-bajpai-
> happy did not evaluable how well Happy Eyeballs handles a broken IPv6 or
> broken IPv4 path.  Instead, what draft-bajpai-happy measured was how well
> the selected path functioned.  

Well, it offer an ROFL moment with 
"will never use Teredo IPv6 unless IPv4 connectivity is broken"
clearly lacking the understanding that IPv4 is required to work for Teredo
to function...

> Happy Eyeballs biases its path selection
> towards IPv6 by design (150-250ms timeout is suggested in
> http://tools.ietf.org/html/rfc6555#section-5.5).  The justification for
this
> delay is explained in "Delay IPv4",
http://tools.ietf.org/html/rfc6555#section-
> 4.1, and was consensus of the working group primarily because it (a)
mimics
> the long-standing IETF view that IPv6 should be preferred over IPv4 (b)
> reduces connection attempts on servers and (c) minimizes the harm to IPv4-
> only devices sharing an IPv4 address with the dual-stack client (as those
IPv4-
> only devices cannot use IPv6).  

If the IPv6 path is not given an automated preference the traffic will never
move. Even with emerging deployment on 'services', the cache topologies are
not identical in every instance, and getting them there requires
demonstrated traffic. People continue to complain that IPv6 traffic levels
are low, but they will continue that way until ISP's and content providers
make everything identical between the protocol versions. Given that many use
lack of traffic at other sites as an excuse for not doing their own
deployment, breaking the stalemate requires a bias.

> Happy Eyeballs' algorithm differs from Apple's
> algorithm (introduced in OS X 10.7) which uses whichever path connects
first
> (for details see http://lists.apple.com/archives/ipv6-
> dev/2011/Jul/msg00009.html), which I expect would result in better results
if
> tested using the test methodology of draft-bajpai-happy.  However, even
> with Apple's algorithm if a path connects quickly but the path performs
> poorly (e.g., low bandwidth) the user experience will suffer.  Happy
Eyeballs
> can perform similarly to Apple's algorithm (but not identically) by
setting its
> connection delay to 0ms.

Apple's implementation is "not helpful". They start by refusing to allow
modifications to the 3484 policy table to meet local policies, then follow
that with a refusal to ack that the IPv4 cache nodes are generally closer to
the request than the IPv6 ones, so traffic stays on IPv4 when it could &
should have moved. Anything less than a 100ms delay for the IPv4 request is
essentially guaranteeing that the traffic stays on IPv4, until the cache
topology catches up, which will never happen if the traffic loads can't
justify it. 

Tony