Spontaneous "Idle Timeouts" when IdleTimeoutMs is set to zero

[cjgatto]

QUIC_SETTINGS IdleTimeoutMs is set to 0

According to https://github.com/microsoft/msquic/blob/main/docs/Settings.md, setting this timeout to 0 disables timeout.

However, I'm receiving QUIC_STATUS_CONNECTION_IDLE QUIC_CONNECTION_EVENT from the connection callback handler. Prior to sending this, the connection and streams are seemingly healthy, from both QUIC client and server perspectives. Is there another scenario where QUIC_STATUS_CONNECTION_IDLE is sent?

Note: Under normal conditions I leave the timeout default at 30s. I was able to reproduce this issue with IdleTimeoutMs set to 0, which seems suspicious if this is an "actually timeout" event

[nibanks]

Are you configuring a zero timeout on both sides of the connection? This timeout is negotiated as the minimum between each side's choice. So if you disable the timeout, but the peer says 30 seconds, then the timeout is 30 seconds.

[cjgatto]

Good point, the client is set to a 30 second timeout. The server definitely receives data from some of the client streams right up until the connection idle event is handled by the server. Working in a degraded network, I would guess it's possible that the client failed to receive QUIC ACKs for 30 seconds, and terminated the connection?

[cjgatto]

Or would the scenario, not receiving ACKs, fall under the DisconnectTimeoutMs setting?

How long to wait for an ACK before declaring a path dead and disconnecting.

Is "path" here referring to the connection? Or a stream?

[nibanks]

I think grabbing logs might be helpful to diagnose your specific issue. Path is the UDP 4-tuple.