Re: [v6ops] Measuring the Effectiveness of Happy Eyeballs

["Bajpai, Vaibhav" <[e-mail]>]

On Jul 8, 2013, at 6:05 PM, Dan Wing <[e-mail]> 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:
>> 
>> [...]
> 
> I noticed when this was published and presented earlier at
> https://ripe66.ripe.net/presentations/263-ripe66-happy-slides.pdf.  

Thank you for noticing it :-)

> 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.
> 
> 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.  

Yes! this is true. This is because we _wanted_ to measure in a real 
uncontrolled environment. We wanted to know: if all the applications today
get happy eyeballed, how would the dual-stack user experience be? This why
we made significant effort to find and deploy probes and measure from 
behind a residential gateway of a real dual-stack host.

We don't change the network conditions, we only measure what the end-host
might experience from a happy eyeballed application. Therefore, we think
we do measure happy eyeballs on how it would perform in the wild today.

> 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 draft mentions that 300ms is used in Chrome and Firefox. Since, the
implementations are using their own timer value than what is recommended,
it would be nice to know what would be a better timer value, by directly
measuring from deployed dual-stacked hosts, no?

> 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).

We understand it's a policy discussion to facilitate IPv6 adoption. We will
add a section describing this policy decision. We will also add a section in
the draft to clarify the motivation of RFC6555.

Best, Vaibhav

> 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.

-----------------------------------------------------
Vaibhav Bajpai

Research I, Room 86
Computer Networks and Distributed Systems  (CNDS) Lab
School of Engineering and Sciences
Jacobs University Bremen, Germany

www.vaibhavbajpai.com