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

Robin Whittle <rw@firstpr.com.au> Tue, 13 November 2012 07:34 UTC

Return-Path: <rw@firstpr.com.au>
X-Original-To: rrg@ietfa.amsl.com
Delivered-To: rrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B6321F88CB for <rrg@ietfa.amsl.com>; Mon, 12 Nov 2012 23:34:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.226
X-Spam-Level:
X-Spam-Status: No, score=-1.226 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ON-3bUtEMjaG for <rrg@ietfa.amsl.com>; Mon, 12 Nov 2012 23:34:51 -0800 (PST)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by ietfa.amsl.com (Postfix) with ESMTP id 38FAE21F888E for <rrg@irtf.org>; Mon, 12 Nov 2012 23:34:46 -0800 (PST)
Received: from [127.0.0.1] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 788A0175A93; Tue, 13 Nov 2012 18:34:44 +1100 (EST)
Message-ID: <50A1F7CF.2080402@firstpr.com.au>
Date: Tue, 13 Nov 2012 18:33:35 +1100
From: Robin Whittle <rw@firstpr.com.au>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
References: <A5F253CD-71F6-49BD-95CC-897F803860F1@gmail.com> <50A19CA4.8000007@firstpr.com.au> <44EED7F5-2C8E-4784-B72D-EF28C8366F61@castlepoint.net> <50A1CB11.4050809@firstpr.com.au> <78553EF9-D0D4-4914-89CC-E9CC1F435FDB@castlepoint.net> <50A1DF3F.6020801@firstpr.com.au> <05AD8FE9-B1D1-4694-9F69-61260B0FC1DA@castlepoint.net>
In-Reply-To: <05AD8FE9-B1D1-4694-9F69-61260B0FC1DA@castlepoint.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [rrg] Happy Eyeballs RFC6555: app changes so dual-stack IPv4/6 is usable
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Nov 2012 07:34:52 -0000

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

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

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.

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

  - Robin