Is the IdleTimeout setting description correct?

[bentoi]

The documentation of the IdleTimeout setting explains that the connection is closed gracefully if the connection is idle after IdleTimeout. Is this really correct?

The Quic's spec specifies that the connection should be silently closed if it's idle. The msquic implementation also appears to perform a silent close

msquic/src/core/connection.c

Line 6151 in 4bcd6e8

QUIC_CLOSE_INTERNAL_SILENT | QUIC_CLOSE_QUIC_STATUS,

when the idle timer is triggered.

As written today, it sounds like the IdleTimeout is about gracefully closing inactive connections but afaict it's about detecting a connection loss when the connection has outstanding packets waiting to be ACKed. Is this correct?

[nibanks]

The documentation is wrong. It should be "silently shut down" instead of "gracefully shut down". Thanks for the find!

[bernardnormier]

HTTP/3 clients would dynamically enable keep alives

They would do so by setting KeepAliveInterval on the connection, or does msquic provide another API?

so that the server can respond without fear of the path being killed (i.e., every ~20 seconds)

The concern here is the negotiated idle timeout, not a well-known timeout value like 20 seconds. The http/3 client needs to send keep alives (PING frames) at intervals lower than this negotiated idle timeout.

Is it possible to retrieve this negotiated idle timeout?

[nibanks]

They would do so by setting KeepAliveInterval on the connection, or does msquic provide another API?

Yes.

The concern here is the negotiated idle timeout, not a well-known timeout value like 20 seconds. The http/3 client needs to send keep alives (PING frames) at intervals lower than this negotiated idle timeout.

Is it possible to retrieve this negotiated idle timeout?

Not currently, but that'd be super easy to expose via some new GetParam for the connection, something like QUIC_PARAM_CONN_NEGOTIATED_IDLE_TIMEOUT. If you'd like this, please open a feature request. That being said, if a peer does this, (1) they are explicitly not wanting to keep a connection open long, and (2) it's most likely simply a configuration bug, and you might not want to cover that up by setting super aggressive keep alives.

What do you want to do if the peer configured a 5 second idle timeout? Do you really want to configure 2-3 second keep alives?

[bernardnormier]

What do you want to do if the peer configured a 5 second idle timeout? Do you really want to configure 2-3 second keep alives?

This should be up to the application. msquic could support a min value for the negotiated timeout (the connection establishment fails if the peer sends a lower max_idle_timeout).

Or the application could retrieve this negotiated idle timeout and abort the connection if it's too low.

Not currently, but that'd be super easy to expose via some new GetParam for the connection, something like QUIC_PARAM_CONN_NEGOTIATED_IDLE_TIMEOUT. If you'd like this, please open a feature request.

My preference would be to have a simpler API, where the application (= the application protocol using msquic) can instruct msquic to keep the connection alive. A simple on/off switch.

When "keep alive" is on, msquic figures out when / how often to send PING frames to the peer, based on the negotiated idle timeout. When "keep alive" is off, msquic doesn't send PING frames.

Does this sound reasonable?

[nibanks]

Please open a feature request with all the details. Thanks!

[bernardnormier]

See #3880