Re: [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-08.txt

Leo Gaspard <leo@gaspard.io> Mon, 26 June 2017 22:42 UTC

Return-Path: <leo@gaspard.io>
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD31412702E for <sunset4@ietfa.amsl.com>; Mon, 26 Jun 2017 15:42:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.035
X-Spam-Level:
X-Spam-Status: No, score=-4.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=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 zWPN9RKa461W for <sunset4@ietfa.amsl.com>; Mon, 26 Jun 2017 15:42:50 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53BB6126E3A for <sunset4@ietf.org>; Mon, 26 Jun 2017 15:42:50 -0700 (PDT)
Received: from [192.168.43.167] ([77.154.204.178]) by mwinf5d51 with ME id dain1v00B3rTkoD03aina5; Tue, 27 Jun 2017 00:42:48 +0200
X-ME-Helo: [192.168.43.167]
X-ME-Auth: bGVvLmdhc3BhcmRAd2FuYWRvby5mcg==
X-ME-Date: Tue, 27 Jun 2017 00:42:48 +0200
X-ME-IP: 77.154.204.178
To: sunset4@ietf.org
References: <149849684615.18420.14124996388059665238@ietfa.amsl.com> <8567A66E-28E0-4B52-95A8-371B6100622B@consulintel.es>
From: Leo Gaspard <leo@gaspard.io>
Message-ID: <ff52f417-46e1-e3ad-b7dc-55ed05479202@gaspard.io>
Date: Tue, 27 Jun 2017 00:42:43 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0
MIME-Version: 1.0
In-Reply-To: <8567A66E-28E0-4B52-95A8-371B6100622B@consulintel.es>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="0jHVtUg1tQk3SEacE7mLuqaVk0Pm9kLdK"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sunset4/Z6nXlYHQG2XESDbWfXx28ljYiG8>
Subject: Re: [sunset4] I-D Action: draft-ietf-sunset4-gapanalysis-08.txt
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: sunset4 working group discussion list <sunset4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sunset4>, <mailto:sunset4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sunset4/>
List-Post: <mailto:sunset4@ietf.org>
List-Help: <mailto:sunset4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sunset4>, <mailto:sunset4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Jun 2017 22:42:53 -0000

On 06/26/2017 08:05 PM, JORDI PALET MARTINEZ wrote:
> Regarding the different issues that are indicated because Happy Eyeballs, a possible solution is to increase the timers, so even if IPv6 is “slower” than IPv4, is not just a matter of 50 milliseconds (for example), but several seconds, so then IPv6 will get preference anyway. I’ve described this in a recent email related to the HE-update document (so you could use some of the text that I mention in that email):

Please be careful about this (for problem 6): I've already seen people
advising to "just disable IPv6 to get a speed boost." If the timeout is
going to slow down to several seconds, this may make more people switch
to using IPv4 only, which would be the complete opposite of the objective.

Sure, you also consider making this setting a knob, but people may go
the easiest already known way, because "well, who cares about IPv6 anyway?"

Then, all this depends on the proportion of the internet that is already
quickly IPv6-reachable, but if there is a problem to solve, it can only
be solved by making IPv4 slower when IPv6 is enabled... which sounds
like a bad idea to me so long as IPv4's sunset (or IPv6's rise?) isn't
complete yet (at which point this solution is no longer needed anyway).

Best regards,
Leo