That might be fixable -- what kind of timeouts are you hitting, and for what application protocols?
There's no concept of "idle" at the networking (IP, TCP, UDP) level. There are packet response timeouts at the kernel level, but that has always been true.
Some applications (e.g. sshd) also have session idle/timeout settings, but they are just administrative hygiene decisions and usually easy to override. Definitely easy if you control the server, and the ssh client has a KeepAlive config setting if you do not.
> with no timeouts any malicious actor could tie up all a server's port, for example
This might be a misunderstanding. Ports do not get tied up. A server can be overwhelmed with traffic, but that requires packet volume (e.g. DoS attack) and it doesn't matter what ports are used.
All application protocols today have very short timeouts, typically in the few tens of seconds range. Most TCP stacks have a 10 minute timeout by default, if I recall the value correctly - if a sent packet has not been ACKed within that range, the connection is aborted. DNS resolvers typically have a similar timeout.
And as for servers, while you're right of course that server ports don't get tied up, there is typically some memory cost to maintaining an application-level connection, even if idle. I don't know of any common HTTP server for example that, in its default settings, doesn't close connections after some short idle time, for this very reason. More sophisticated attacks, like SlowLoris, have been created for this very reason. A server which doesn't timeout idle connections can easily be DoSed by a handful of compromised clients.
That should be more common in CGNAT or mobile networks than home/office networks. Although I don't know what residential ISPs are up to these days. No doubt some sketchy practices have crept in.
For that matter, it could be a low-RAM (carrier-provided?) NAT gateway (or very high network activity) at the premises, blowing up the NAT table.
Still, could be fixable. If the application protocol has some kind of keepalive heartbeat, or if local hardware can be configured or upgraded.
There's no concept of "idle" at the networking (IP, TCP, UDP) level. There are packet response timeouts at the kernel level, but that has always been true.
Some applications (e.g. sshd) also have session idle/timeout settings, but they are just administrative hygiene decisions and usually easy to override. Definitely easy if you control the server, and the ssh client has a KeepAlive config setting if you do not.
> with no timeouts any malicious actor could tie up all a server's port, for example
This might be a misunderstanding. Ports do not get tied up. A server can be overwhelmed with traffic, but that requires packet volume (e.g. DoS attack) and it doesn't matter what ports are used.