Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications

Owen DeLong <> Mon, 22 June 2015 21:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2DF8F1AD36E for <>; Mon, 22 Jun 2015 14:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.111
X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L55oqfLHEiET for <>; Mon, 22 Jun 2015 14:53:17 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id 64DEE1AD366 for <>; Mon, 22 Jun 2015 14:53:17 -0700 (PDT)
Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by (8.14.4/8.14.2) with ESMTP id t5MLrGr0009186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 14:53:16 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Owen DeLong <>
In-Reply-To: <>
Date: Mon, 22 Jun 2015 14:53:15 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Iljitsch van Beijnum <>
X-Mailer: Apple Mail (2.2098)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 ( [IPv6:2620:0:930::200:2]); Mon, 22 Jun 2015 14:53:16 -0700 (PDT)
Archived-At: <>
Cc:, Vividh Siddha <>
Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Jun 2015 21:53:18 -0000

> On Jun 22, 2015, at 13:50 , Iljitsch van Beijnum <> wrote:
> On 22 Jun 2015, at 18:49, Owen DeLong <> wrote:
>>> So if you guys currently look at the RTT for the three-way handshake, it would probably help if you could look at the RTT for data packets instead.
>> Pretty hard to look at the data RTT when establishing a connection. How do you see that working?
> I don't know the details of Apple's (or anyone else's) happy eyeballs implementation. If they set up connections, measure the RTT for the three three-way handshake and then abandon the higher RTT session, or initiate connections in parallel and only pursue the one that connects first, then you're right, this would be a problem. On the other hand, if they do an HTTP request over IPv4 and one over IPv6, then an RTT for data segments would be available.

The few tcpdump logs I’ve looked at would seem to indicate that most (including Apple’s) HE implementations I’ve encountered do the former rather than the latter. Also as near as I can tell, state isn’t tracked from one connection to the next, each new connect() loop sprays a new set of SYNs and then abandons all but the one it selects.