Configuring MsQuic connection timeout

[ez74]

Is there a way to control the maximum time between calling ConnectionStart to the final connection callback?
Following ConnectionStart, our application waits for IdleTimeoutMs (30 seconds) and expects no more connection callbacks after this timeout. We want to decrease the time the application waits after ConnectionStart.
When we set IdleTimeoutMs to 15, we see that when the connection is idle, the callback QUIC_CONNECTION_EVENT_SHUTDOWN_COMPLETE returns after 20 seconds, although IdleTimeoutMs = 15.
In MsQuic Settings, there are several time settings like HandshakeIdleTimeoutMs, DisconnectTimeoutMs, DestCidUpdateIdleTimeoutMs.
Is the time from ConnectionStart to callback response affected by them? If so, how do they affect it?

[nibanks]

IdleTimeoutMs and HandshakeIdleTimeoutMs are just for "idle timeouts" which means "How long do you keep the connection open if there is no data to exchange?". The HandshakeIdleTimeoutMs is specifically during the handshake, and the other one is after.

The DisconnectTimeoutMs is means "How long do you keep trying/resending without getting any acknowledgement?" and is probably closer to what you're looking for.

[nibanks]

BTW, you can use QUIC_PARAM_CONN_SETTINGS to set just a single connection's settings (including the timeout above).

[ez74]

Thank you for your helpful answer. Additionally, in our testing environment, we have a server with an invalid DNS configuration, and when the client tries to resolve this server, the DNS server returns a failure, no such name.
The following strange behavior occurred when we tried to connect to that server by calling ConnectionStart:
During the network capture, we don't see any client requests over QUIC port 443, only DNS queries and responses to the DNS server for around 15 seconds.
Approximately 20 seconds after calling ConnectionStart, the application receives connection callback QUIC_CONNECTION_EVENT_SHUTDOWN_INITIATED_BY_TRANSPORT with the error CONNECTION_IDLE.
Is it possible to configure the DNS resolving timeouts in such a scenario?
The return error CONNECTION_IDLE doesn't seem to fit this scenario. Can the error in such a situation be changed to something more meaningful?

[nibanks]

Is it possible to configure the DNS resolving timeouts in such a scenario?

We simply call blocking API calls for DNS right now, so there is no way to specify a timeout there.

The return error CONNECTION_IDLE doesn't seem to fit this scenario.

Yeah, perhaps. On one hand, the QUIC layer is idle because it hasn't sent anything, but maybe we should just simply treat idle timeout during handshake as a handshake failure instead?

[ez74]

A way to indicate between idle connection due to handshake failure or the layer hasn't sent anything, will be helpful.