Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Fernando Gont <fgont@si6networks.com> Fri, 01 November 2019 08:16 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57199120818 for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 01:16:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 dZk9DkkuK_i5 for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 01:16:10 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93D1120860 for <v6ops@ietf.org>; Fri, 1 Nov 2019 01:16:09 -0700 (PDT)
Received: from [192.168.1.36] (unknown [177.27.208.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8168B8690D; Fri, 1 Nov 2019 09:16:06 +0100 (CET)
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Ted Lemon <mellon@fugue.com>, v6ops list <v6ops@ietf.org>
References: <CAO42Z2yQ_6PT3nQrXGD-mKO1bjsW6V3jZ_2kNGC2x586EMiNZg@mail.gmail.com> <B53CE471-C6E8-4DC1-8A72-C6E23154544F@fugue.com> <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com> <CAO42Z2w5kDSMXCUTM3nQNO_Jhm0ShTo9OW_njLsno7Dhk7LLdw@mail.gmail.com> <abbf9cae-5ed1-add6-a963-83edf671b5aa@si6networks.com> <CAO42Z2xJaGQQ1kiU4c=wJr0ZGJqbfQb5MFn_77cr7DYY3DLUVg@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Openpgp: preference=signencrypt
Message-ID: <c04331fd-6552-7c2a-337d-1e26c76aa7b8@si6networks.com>
Date: Fri, 1 Nov 2019 04:29:38 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAO42Z2xJaGQQ1kiU4c=wJr0ZGJqbfQb5MFn_77cr7DYY3DLUVg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/83x56WjdHjKXiq1uFQCFqKALYe8>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 01 Nov 2019 08:16:19 -0000

On 1/11/19 03:49, Mark Smith wrote:
> 
> 
> On Fri, 1 Nov 2019, 14:31 Fernando Gont, <fgont@si6networks.com
> <mailto:fgont@si6networks.com>> wrote:
> 
>     On 31/10/19 21:20, Mark Smith wrote:
>     >
>     >
>     > On Fri, 1 Nov 2019, 06:34 Ted Lemon, <mellon@fugue.com
>     <mailto:mellon@fugue.com>
>     > <mailto:mellon@fugue.com <mailto:mellon@fugue.com>>> wrote:
>     >
>     >     On Oct 31, 2019, at 3:21 PM, Fernando Gont
>     <fgont@si6networks.com <mailto:fgont@si6networks.com>
>     >     <mailto:fgont@si6networks.com <mailto:fgont@si6networks.com>>>
>     wrote:
>     >>     On 27/10/19 09:02, Ted Lemon wrote:
>     >>>     Indeed, this would also not actually solve the problem.   At
>     present,
>     >>>     the ISPs are doing something that is out of spec and causes
>     problems.
>     >>>     If we “fix” this by accommodating what they do, does that
>     help, or
>     >>>     does it just encourage them to continue doing it?
>     >>
>     >>     Did happy eyeballs encourage broken IPv6 connectivity, or did it
>     >>     actually help IPv6 deployment?
>     >
>     >     Don’t get me wrong—I’m not saying we shouldn’t do things to
>     improve
>     >     the situation.   I am saying that we should be strategic about it.
>     >
>     >>>     What should be happening on the host with a prefix that’s
>     deprecated
>     >>>     is that TCP connections should be timing out.   This doesn’t
>     take
>     >>>     very long.  
>     >>
>     >>     ~9 minutes, IIRC.
>     >
>     >     Should be 90 seconds.
>     >
>     >
>     > You've got no more than 10 seconds unless you want end users to
>     actively
>     > try to do something to recover, which can include calling their ISP's
>     > helpdesk.
> 
>     I'd argue the opposite..
> 
> 
> 
> I wouldn't argue with research from 1968, referenced in an article from
> 1993, by an expert in usability, cited in my slides.
> 
> 
>   Response Times: The 3 Important Limits
> 
> https://www.nngroup.com/articles/response-times-3-important-limits/

What I meant is that I wouldn't expect you to deal with this at the
transport layer, but at the app layer. Setting timers to small values at
the transport layer is asking for all sort of failures. -- and not only
that: you could have situations in which the transport-layer timers
don't go off (say, you do get some data at the transport layer), but you
don't get the app protocol-data-units that you can act upon.



[....]
> 
> It not being in control of the user is the point of knowing UX/HCI
> factors so the good default response times can be chosen.
> 
> TCP's default timeouts are way too large for a good end user experience.
> I don't know what criteria were used to select them, but it certainly
> wasn't human usability factors.

TCP is not optimized for anything (although IIRC there are now
"flavours" of TCP popping up). TCP simply aims at reliability, so that,
unless there's an unrecoverable error, TCP does it best to make the data
delivered to the remote TCP. The long user timeout means that transient
network errors can be recovered.

Similarly, TCP has an exponential back-off -- something that will likely
not relate into nice response times.

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492