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

Mark Smith <markzzzsmith@gmail.com> Fri, 01 November 2019 06:49 UTC

Return-Path: <markzzzsmith@gmail.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 B3DA612002E for <v6ops@ietfa.amsl.com>; Thu, 31 Oct 2019 23:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.496
X-Spam-Level:
X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 aQeVJSPZNcdC for <v6ops@ietfa.amsl.com>; Thu, 31 Oct 2019 23:49:29 -0700 (PDT)
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A4712001E for <v6ops@ietf.org>; Thu, 31 Oct 2019 23:49:28 -0700 (PDT)
Received: by mail-oi1-x22b.google.com with SMTP id v186so7395387oie.5 for <v6ops@ietf.org>; Thu, 31 Oct 2019 23:49:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MTU2RZEndXNXGJt46QX4cXwQs4998Kg0Qhd3iVflsMM=; b=dxNZCC2i/Ct1p+8Z9KP5ZRCDUA69it+On2Tv4M8fIUX4mFPAPENLW1TUr/JkqRd5aJ grB7qjzwKDg901oUMHewlqwiAg/CJbjGQ84c7rrpnlBOi1lNgCOe3UV2msn6Wy+0Oq+X FhcmqOE4I8ql8sl9ox2WaVYFJCjvHVU+yJr2VE7fFlq0vZ/BT0V3Nqj07ODZzDJmh1cx /gN0g02q//QfFLirXqWAXd/XMmLJKh+KhiKMDNha1rjiY9NhW6R5gl3m/DPivUIyxQID IC8dhVt6+fq4qCyF9P+3BgxuB+3R8kGJTpfCDtzYWQqVNEJevuisHFKHF83UDqMUSowN LSkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MTU2RZEndXNXGJt46QX4cXwQs4998Kg0Qhd3iVflsMM=; b=pZ3YybU8ll44oVCa1qKaYc6OxZEvvmZtpmWkftgY15/MoZEy38hK1tVaVV9et5bnBb 1NQQu+cUN7nfoCPvz1Zrpl3T17aN+WbwPDc5lUhmyFLMQLIqdchHEBkhQGa9qWhtqFks iVJU1GnhKYESV1xdZLNe/M+sTd3CvAMU2mNMMueEriCe/VQ+6M+eL6efmXhNsbJ7OHRC VivAieduxmcXEcaAJEu2evqKfI8VQd8eMsWCGPcnivteYm1JRmDMdm8cy2D2W9s/9Bc4 39XpbpcxJOtubxLC+HQy0uIFmyyKR8PCEBvzB9z8RTlWIEHiqohZ9/ti1sbDE8UKsKYD OkBg==
X-Gm-Message-State: APjAAAX2Blw++kSAXze+ru9Fnsx8Vws/xABwksAKLuhimyjCGqnIH103 KizZrJ5X4kB12yEqSsjE1k+VAO2HyujAMmCkx8Mjqg==
X-Google-Smtp-Source: APXvYqyrPHcSKqARiYPt6eyWFbxsf/ZkVwf/AxvccyVjS0AbpEjluDo7fkk2SOxTCXeoLNhfSXcjRQazuVnvl08tMrI=
X-Received: by 2002:a54:4198:: with SMTP id 24mr4037393oiy.164.1572590968223; Thu, 31 Oct 2019 23:49:28 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <abbf9cae-5ed1-add6-a963-83edf671b5aa@si6networks.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Fri, 01 Nov 2019 17:49:17 +1100
Message-ID: <CAO42Z2xJaGQQ1kiU4c=wJr0ZGJqbfQb5MFn_77cr7DYY3DLUVg@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: Ted Lemon <mellon@fugue.com>, v6ops list <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000009bd4d0596435e2a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/rur0-5hBw4NACB_JwqDGMaG4yhc>
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 06:49:31 -0000

On Fri, 1 Nov 2019, 14:31 Fernando Gont, <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>> wrote:
> >
> >     On Oct 31, 2019, at 3:21 PM, Fernando Gont <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/



But, anyway, for the most part the user timeout
> is not under the control of the user.
>


I don't understand this.

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.





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