Re: [v6ops] enable-ula.py

[Mark Smith <[e-mail]>]

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.

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.
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops