Re: [v6ops] enable-ula.py

[Bob Harold <[e-mail]>]

On Sun, May 15, 2022 at 6:51 PM Mark Smith <[e-mail]> wrote:

> Hi,
>
> On Mon, 16 May 2022, 04:35 Philip Homburg, <[e-mail]>
> wrote:
> >
> > > The goal is noble. I think that making it general-purpose, in the
> > > way that the socket API is general-purpose, will be very hard. Will
> > > it become the standard answer to all relevant questions on Stack
> > > Overflow?
> > >
> > > So, despite that effort, and all Eduard's arguments, I think that
> > > the best we can do here is focus on making RFC6724 work better.
> > > Even that requires getting getaddrinfo() developers to work for
> > > us.
> >
> > Getaddrinfo is important for two reasons:
> > 1) It is all we have, and it is unlikely we will get something better.
> > 2) There is a lot of code that uses getaddrinfo and then follows with a
> >    synchronous loop over the struct addrinfo entries.
>
>
> I think the more fundamental issue is that default DNS resolver and
> TCP transport layer protocol connection establishment timeouts are
> terribly un-user friendly these days. They would have been back in the
> 80s too when they were chosen, so I'm not sure what motivated them
> being so large.
>

Back then, there were modem links that auto-dialed when there was traffic,
and that took a while to make a connection.  Computers and links were much
slower back then.  Yes, we should update the timeouts, but there was a
reason why they were set that way.

-- 
Bob Harold


>
> For example, on current Fedora Linux, a TCP connection to a
> destination that doesn't exist took 2 minutes and 12 seconds to
> timeout:
>
> [mark@opy ~]$ date; telnet 8.8.8.9; date
> Mon 16 May 2022 08:24:50 AEST
> Trying 8.8.8.9...
> telnet: connect to address 8.8.8.9: Connection timed out
> Mon 16 May 2022 08:27:02 AEST
> [mark@opy ~]$
>
> Going by "Response Times: The 3 Important Limits" (
> https://www.nngroup.com/articles/response-times-3-important-limits/ )
> an application connection attempt should take no more than 10 seconds
> before the end-user gets some feedback either on progress or that it
> has failed.
>
> So I think the goal for connection attempting the average number of
> DAs that getaddrinfo() returns needs to be a total of 10 seconds. Much
> lower DNS timeouts and TCP etc. connection timeouts would facilitate
> sequential connection attempts within a much more user friendly time
> period.
>
> I realise that this WG is not the place to solve DNS and transport
> layer timeouts, however I think it is an impossible thing to solve
> entirely with IPv6 SA/DA address selection changes and getaddrinfo()
> when the overriding constraint are these un-user friendly DNS and TCP
> etc. timeouts.
>
> Regards,
> Mark.
>
> >
> > So we have to make getaddrinfo work as well as we can. In particular,
> > we need to make the chance as high as possible that a connection to
> > the first struct addrinfo entry succeeds (based on local knowledge).
> >
> > That said, getaddrinfo is relic of the past. It probably was a nice step
> > forward 20 years ago. Now is the wrong tool.
> >
> > Fixing getaddrinfo is like coming up with a better design for a steam
> > engine. Not because steam engines are so great. But because we completely
> > failed to have a standard for anything more modern.
> >
> > I don't claim to know what a modern tool should look like. But we are
> stuck
> > in the past. We can't try anything new to see if it works and what the
> > limitations are.
> >
>