IETF Logo Mail Archive

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

Iljitsch van Beijnum <iljitsch@muada.com> Mon, 22 June 2015 14:33 UTC

Return-Path: <iljitsch@muada.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469BC1ACD7A for <v6ops@ietfa.amsl.com>; Mon, 22 Jun 2015 07:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.39
X-Spam-Level: *
X-Spam-Status: No, score=1.39 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNrxnu6oyHiU for <v6ops@ietfa.amsl.com>; Mon, 22 Jun 2015 07:33:28 -0700 (PDT)
Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97D71ACD76 for <v6ops@ietf.org>; Mon, 22 Jun 2015 07:33:27 -0700 (PDT)
Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:1958:7c15:b74f:e647] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t5MEWDq6030165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jun 2015 16:32:14 +0200 (CEST) (envelope-from iljitsch@muada.com)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <E1C235B5-1421-4DAF-A2F3-F963982233DF@apple.com>
Date: Mon, 22 Jun 2015 16:33:07 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <90744458-CA06-4347-A96B-D649800855D3@muada.com>
References: <E1C235B5-1421-4DAF-A2F3-F963982233DF@apple.com>
To: David Schinazi <dschinazi@apple.com>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/R4PIu7qgko570ZUorvQxOuID_uY>
Cc: v6ops@ietf.org, Vividh Siddha <vsiddha@apple.com>
Subject: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2015 14:33:29 -0000

On 19 Jun 2015, at 23:46, David Schinazi <dschinazi@apple.com> wrote:

> *) Happy Eyeballs
> We've heard feedback on our Happy Eyeballs implementation and are investigating
> this topic.

> Note that this reflects how these technologies work in the current versions of the
> 2015 betas, many of these details could change in future betas. Please keep in mind
> that these betas are previews and we welcome feedback on improving them.

> Feel free to contact me if you have any questions, I will also attend IETF93.

Ok, here's some feedback on happy eyeballs, to the list so maybe others can improve upon it.

It would be extremely useful to be able to temporarily force IPv6 first or IPv4 first rather than have happy eyeballs for testing purposes.

At NANOG and the RIPE meeting recently, people have presented results that show that IPv6 frequently performs better than IPv4, although the RTT isn't better. It's unclear why this is, but my theory is that the correlation between networks with good performance and networks with IPv6 enabled is high and thus sometimes the IPv4 path goes through a "bad" IPv4-only network which obviously isn't available to IPv6 packets, which then flow through an alternative IPv6-enabled path over a "good" network.

The extra 20 bytes of IPv6 header add about 25% to a SYN while data packets are the same 1500 bytes. 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.

And maybe the RTT is the same but the (congestion) window is smaller on IPv4. Perhaps a NAT messes with the window scale option? So maybe look at the IPv4 vs IPv6 window sizes. I would suggest something along these lines:

if v4RTT < v6RTT - 25 then return IPv4
if v4window / v4RTT > v6window / v6RTT * 1.2 then return IPv4
return IPv6

About the test DNS64/NAT64 implementation:

Obviously the test network isn't a "real" NAT64 test network when there's no native IPv6 present. And obviously there's no easy way to have native IPv6 materialize out of thin air. But someone who wants to test more thoroughly may want to get native IPv6 or set up a tunnel broker tunnel. It would be nice if the test NAT64 setup could work with that, so the devices on the test network can connect to IPv6 destinations over IPv6 and IPv4 destinations through the NAT64.

Basically, what's needed for this is that if the interface in question is configured with "real" IPv6 addresses, those are kept and the prefix in question is advertised in RAs.

v2.23.0 | Report a Bug | By Email