From https://github.com/grpc/grpc/blob/master/doc/keepalive.md, grpc.keepalive_permit_without_calls is described as:
This channel argument if set to 1 (0 : false; 1 : true), allows keepalive pings to be sent even if there are no calls in flight.
My understanding is that this means that it would continue sending keepalives even when there are no active RPCs. But why would we want/need to do this?
Is it to keep an idle gRPC connection alive even though it's not sending any RPCs?
Also, it seems like grpc.max_connection_idle_ms is set to infinity according to https://github.com/grpc/grpc/blob/95c57d9ff5afe1b46069ab7a4189dc95f9b5c174/src/core/ext/filters/channel_idle/channel_idle_filter.cc#L65
const auto kDefaultMaxConnectionIdle = Duration::Infinity();
So would we only need that if maxConnectionIdle is non-zero?
The reasoning here is very similar to TCP keepalives.
One reason you would set grpc.keepalive_permit_without_calls is to prevent disconnection due to network inactivity. It's common for proxies/firewalls to close down connections if there is no activity on them at all, so this helps in scenarios where you would prefer the connection to be alive.
The idleness timeouts achieve the opposite effect in a way, where you would prefer moving the channel from a connected state to an idle state, if there are no active calls.
Note that these two channel args work at different layers, so sending keepalives will not prevent the idleness timeout from closing the channel (since the idleness arg looks at active streams and not network activity).