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
- [rrg] Updating hosts RJ Atkinson
- [rrg] ILNP: existing applications & other critiqu… Robin Whittle
- Re: [rrg] ILNP: existing applications & other cri… Shane Amante
- Re: [rrg] ILNP: existing applications & other cri… Robin Whittle
- Re: [rrg] ILNP: existing applications & other cri… Shane Amante
- Re: [rrg] ILNP: existing applications & other cri… Mikael Abrahamsson
- [rrg] Happy Eyeballs RFC6555: app changes so dual… Robin Whittle
- Re: [rrg] Happy Eyeballs RFC6555: app changes so … Shane Amante
- Re: [rrg] Happy Eyeballs RFC6555: app changes so … Robin Whittle
- Re: [rrg] Happy Eyeballs RFC6555: app changes so … Dan Wing