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

[Fernando Gont <[e-mail]>]

On 1/11/19 03:49, Mark Smith wrote:
> 
> 
> On Fri, 1 Nov 2019, 14:31 Fernando Gont, <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     On 31/10/19 21:20, Mark Smith wrote:
>     >
>     >
>     > On Fri, 1 Nov 2019, 06:34 Ted Lemon, <[e-mail]
>     <mailto:[e-mail]>
>     > <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>     >
>     >     On Oct 31, 2019, at 3:21 PM, Fernando Gont
>     <[e-mail] <mailto:[e-mail]>
>     >     <mailto:[e-mail] <mailto:[e-mail]>>>
>     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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492