net: huge battery drain as TCP_KEEPIDLE is too low

[bam80]

Hi,
Here is where system's TCP_KEEPIDLE default value is hard overridden for some reason:

go/src/net/dial.go

Lines 18 to 27 in e428359

	// defaultTCPKeepAliveIdle is a default constant value for TCP_KEEPIDLE.
	// See go.dev/issue/31510 for details.
	defaultTCPKeepAliveIdle = 15 * time.Second
	// defaultTCPKeepAliveInterval is a default constant value for TCP_KEEPINTVL.
	// It is the same as defaultTCPKeepAliveIdle, see go.dev/issue/31510 for details.
	defaultTCPKeepAliveInterval = 15 * time.Second
	// defaultTCPKeepAliveCount is a default constant value for TCP_KEEPCNT.
	defaultTCPKeepAliveCount = 9

As the value is too low, it creates a problem for many Go projects related with mobile connections, causing huge battery drain on many devices.

There is no workaround currently other than patch the suffered projects, one by one.

Here just a few reports I found, but more exist:
gotify/server#343 (comment):

There also exists a system default value (like net.ipv4.tcp_keepalive_time on Linux), but for some reasons, the Go developers decided to ignore it.

9seconds/mtg#526
v2ray/v2ray-core#2564
binwiederhier/ntfy#687
binwiederhier/ntfy#1195
https://discuss.grapheneos.org/d/16042-ntfy-high-battery-usage-on-cellular-but-not-wifi-pixel-8

Proposed solution:
Do not override TCP_KEEPIDLE by default and let system own the default value in net.ipv4.tcp_keepalive_intvl kernel parameter.

[gabyhelp]

Related Issues

• net: default TCP Keep-Alive interval causes significant power usage #48622 (closed)
• net: more detailed TCP keep-alive configuration #62254 (closed)
• net: enable TCP keepalive on new connections from net.Dial #23459 (closed)
• net: use the same default TCPKeepAlive interval in net.Listen and net.Dial #31510 (closed)
• x/net/tcp: shouldn't SetKeepAlive() and SetKeepAlivePeriod() be flagged as deprecated or at least be flagged as conflicting with SetKeepAliveConfig #73401 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

CC @neild

Enabling TCP keepalive by default was discussed in #23459. There was only limited discussion of the specific value to use, which focused on how long it would take for the connection to be shut down (#23459 (comment)).

A shorter limit is appropriate for a server, and personally I think it would be a mistake to change the default to become much longer. That would have a surprising and difficult to detect effect on existing Go servers.

But it is of course reasonable to observe that the default is too long for clients. It would be easy enough to change the default for anrdroid or ios systems specifically, and perhaps that would be a good choice.

[bam80]

Please note server's keepalive settings have direct impact to clients, too, even if they are not Go apps at all:
9seconds/mtg#526

This issue is not about optimal value here, but rather it shouldn't be enforced by Go in the first place, whatever "default" it has in mind.
If someone want's it to be enforced for whatever reason, he still could do so in Go, but that should be opt-in.

Also don't forget the more natural way to regulate keepalive for server would probably be via net.ipv4.tcp_keepalive_intvl kernel parameter, as it's the OS who owns the setting, and we shouldn't break that.
(That would also allow solid behavior and single configurable point for different services, eg. SSH server and the proxy above).

[ianlancetaylor]

Nothing is being enforced here. The only question is the default behavior. Any Go program can change the default, via https://pkg.go.dev/net#KeepAliveConfig as used by https://pkg.go.dev/net#Dialer and https://pkg.go.dev/net#ListenConfig.

The net.ipv4.tcp_keepalive_intvl kernel parameter is not a general setting for keep-alive. It's the default setting for one parameter. It's value, like Go's, is set based on historical settings and rarely changed.

It's worth noting that on my laptop the value is 75, which is not dramatically different from the default that Go uses, which is 15. Given that, I personally would not object to changing the default to be read from that file on Linux systems.

[bam80]

I personally would not object to changing the default to be read from that file on Linux systems.

That would probably solve all that issues I linked.
For most NAT's, the value as much as 600 would probably suffice, but given the responses in the issues above, even 75 should make a big difference.

Reading it from net.ipv4.tcp_keepalive_time would be even better indeed, as we don't hardcode any value that way, and make the system configurable without changing an app.

[Tey]

My analysis on the gotify issue was not fully right: the file net.ipv4.tcp_keepalive_intvl controls the value of TCP_KEEPINTVL (which is what defaultTCPKeepAliveInterval changes). Keep-alive packets are only sent after an idle period is detected and they stop being sent once a response is received, until a new idle period is detected again. So keeping a default of 15 seconds for defaultTCPKeepAliveInterval could be okay.

The main issue is with how long the detection of the idle period is. That's the file net.ipv4.tcp_keepalive_time, that controls the value of TCP_KEEPIDLE (which is what defaultTCPKeepAliveIdle changes). By default, this value is at least 2 hours (7200 seconds) because that's what the original TCP specs mandate (sending packets unnecessarily was discouraged back then). This default value is way too big nowadays, so now I can understand why the Go devs felt the need to change it.
But 15 seconds is clearly too small for battery powered devices. It should probably be set to multiple minutes. Copilot suggested 15 minutes for keep-alive packets as a rule of thumb for mobile energy tradeoffs, but failed to provide authoritative links about that.

The default value should be changed not only for Android or iOS but for all platforms, because if the other side keeps sending keep-alive packets every 15 seconds, this will force the mobile device to wake up that often to process the packet and send the response.

[bam80]

Thanks, I changed it to the net.ipv4.tcp_keepalive_time above.
I still think we should not hardcode any default value here, and let OS manage that.
If for some reason current default is too big there, we can try to change it upstream.
And even if it fails, we should let users regulate it however they want via net.ipv4.tcp_keepalive_time, for Go apps too.

[dr2chase]

@neild @nicholashusin