gRPC Keepalive Limits: Idle-Connection PING Frames Behind Load Balancers

gRPC channels can use HTTP/2 PING frames as a keepalive mechanism, letting a client detect a dead connection within a configured timeout instead of waiting for a long transport-level failure. The decision on the table is whether to enable keepalive on long-lived channels that traverse a managed load balancer or NAT gateway.

Two documented constraints shape that decision. Keepalive pings can be sent even when no streams are active, and some intermediaries treat frequent pings on an otherwise idle connection as abnormal and reset the channel. gRPC servers can also enforce their own keepalive policy, rejecting pings that arrive without active streams or exceed a permitted rate, which surfaces as connection teardown rather than a harmless no-op. Defaults differ across language implementations, so an interval tuned for one client stack may not transfer to another.

1. Under what conditions will server-side keepalive enforcement terminate a channel that pings with no active streams, and how does the client observe that outcome?
2. What ping interval and timeout values are reasonable when the intermediary's idle-timeout policy is unknown?
3. Is there a keepalive configuration that achieves fast dead-connection detection without provoking middlebox resets?