Re: [rrg] Happy Eyeballs RFC6555: app changes so dual-stack IPv4/6 is usable

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Robin Whittle
> Sent: Monday, November 12, 2012 11:34 PM
> To: RRG
> Subject: Re: [rrg] Happy Eyeballs RFC6555: app changes so dual-stack
> IPv4/6 is usable
> 
> Short version: Discussing the implementation of Happy Eyeballs or
>                something similar to it in the operating system, rather
>                than in the application.
> 
> Hi Shane,
> 
> You wrote:
> 
> >> It seems that applications need to be altered, by the addition of a
> >> Happy Eyeballs algorithm, to provide reliable performance when the
> >> dual-stack host is connected to both IPv4 and IPv6.  This is
> >> unfortunate, but not surprising - since these are two separate
> Internets.
> 
> > No. Note that Mac OS X _operating_system_ implements a form of Happy
> > Eyeballs. Thus, there is no need for apps on top of OS X to implement
> > it. IMO, the only reason apps such as Firefox & Chrome have
> > implemented Happy Eyeballs is because Windows does not implement Happy
> > Eyeballs, so the apps vendors were forced to work around it.
> >
> > This illustrates the fundamental conundrum we're facing. Apps vendors
> > are making up for the deficiencies of the underlying operating system
> > network stacks. If we give the O/S vendors something to latch on to,
> > then it makes everyone's lives improved.
> 
> Maybe it is difficult or perhaps impossible to implement Happy Eyeballs
> or the like in the OS in a manner which never causes problems, no matter
> the nature of the application.
> 
> The example algorithm in section 6 of RFC 6555 involves sending a SYN to
> the IPv6 address (assuming the address policy for the host prefers IPv6,
> which I understand is typically the case for a dual-stack OS), waiting
> 300ms and then sending a SYN to the IPv4 address if there was no
> response in that time.  From Australia, and especially on a 3G/4G mobile
> link, 300ms is a rather short time in which to expect a response from
> servers in most of the world. 

Hi.  Happy Eyeballs co-author here.

For a good long while, both Firefox and Chrome will initiate a connection
to the next IP address after 250ms-300ms.  This has worked, with little
notice or fanfare, for years and years.  For Happy Eyeballs, this 
mechanism was modified to be aware of the IP address family so that 
the second connection is always on the other address family.

> Assuming the IPv6 address does produce an
> ACK which arrives later than 300ms, then the host is sending out two
> SYNs instead of one, and likely receiving two SYNs too.  This is
> something of an extra burden on a 3G/4G link.

User experience tends to be in conflict with battery life and network 
utilization.

RFC6555 only suggests timers; different timers could be imagined.  And
Apple's implementation tweaks itself to become sensitive to the actual
connection times seen over v4 and over v6.

> Though Happy Eyeballs is documented for TCP, the Wikipedia page mentions
> it being used to choose between TCP and SCTP.  I don't think it could
> work with UDP, since there is no SYN/ACK arrangement. 

ICE (RFC5245) runs over UDP and was built for NAT traversal and has
a request/response semantic (to determine if a path is viable).  It
is used for IPv6 transition (see RFC6157), and there is ongoing work 
to suggest implementations be more aggressive in trying both address
families instead of trying a huge list of (broken) IPv6 candidate
addresses (see draft-reddy-mmusic-ice-happy-eyeballs).

> A Happy Eyeballs-
> like algorithm could be implemented for UDP with the involvement of the
> server, but this would have to be at the application level.

For UDP, you need a request/response protocol.  Almost all UDP protocols
are request/response (DNS, NTP, ICE (RFC5245)).

> Perhaps this means that dual-stack problems it is intended to solve
> can't be solved for UDP-based protocols without suitable application
> changes for the client and server.

Or, the OS could learn that TCP is not working well to a certain IPv"X"
subnet, but is working well using IPv"Y".  That is exactly what Apple's
OS-based implementation of Happy Eyeballs learns.

> This article from 2011-11-12 may not reflect the current behavior of the
> "Happy Eyeballs" algorithm (it is actually a different algorithm) in OS-
> X:
> 
>   https://labs.ripe.net/Members/emileaben/hampered-eyeballs
> 
> however it does mention how it works, or worked, and some problems which
> arose, presumably with applications which use the traditional
> getaddrinfo() call, rather than another methods which are apparently
> unique to OS-X.
> 
>    "It looks like OS X Lion makes debugging connectivity issues to
>     dual-stacked websites a royal pain, with the associated cost for
>     support staff. While the Mac OS X Lion + Safari combination looks
>     to be a true "Happy Eyeballs" implementation, the combination of
>     OS X Lion with anything that just uses getaddrinfo() does not make
>     the eyeballs much happier it seems."
> 
>   "If the way Mac OS X implemented 'Happy Eyeballs'-like functionality
>    becomes more widespread (please don't do this Microsoft!) it will
>    cause perfectly fine dual-stack hosts with roughly equal performance
>    over both protocols, to select the legacy IPv4 protocol in roughly
>    half of the cases. This makes the IPv6 capacity in networks
>    under-used and that is bad for a  few reasons:
> 
> This page reports on problems with OS-X 10.7 (Lion) in April this year.
> 
>   http://shibboleth.net/pipermail/dev/2012-April/000651.html
> 
> From 2012-08-10 more reports of trouble with OS-X and particular
> browsers - Safari and Firefox:
> 
> 
> http://www.jumpertz.net/1/post/2012/11/going-cross-eyed-with-happy-
> eyeballs.html
> 
> A 2012-09-11 Cisco presentation doesn't mention any difficulties:
> 
> http://www.data.proidea.org.pl/euronog/2edycja/materials/Krzysztof_Mazep
> a-IPv4_vs_IPv6-Happy_Eyeballs.pdf
> 
> Geoff Huston and George Michaelson (2012-04-16) mention various items of
> interest to these questions and mention problems with the OS-X
> implementation.
> 
>   https://ripe64.ripe.net/presentations/78-2012-04-16-ripe64.pdf
> 
> 
> This is not a proper survey of the field.  I am just suggesting that it
> may not be straightforward to implement the Happy Eyeballs algorithm in
> the OS, especially considering that various apps may access the OS in
> different ways, may be doing their own version of Happy Eyeballs etc.
> and that the OS approach might upset some assumptions made in higher
> level protocols.

Yes, it's very difficult to do Happy Eyeballs in the OS.  Especially
that every application has a different definition of what it considers
"happiness".

-d