Keep paths alive on a timer of their own

[masa-koz]

Description

#74 made the keep alive PING go out on every path, but hung that off QUIC_CONN_TIMER_KEEP_ALIVE — the wrong timer. QuicConnResetIdleTimeout re-arms it on every ack-eliciting packet received and on the first packet put in flight:

    if (Connection->Settings.KeepAliveIntervalMs != 0) {
        QuicConnTimerSet(
            Connection,
            QUIC_CONN_TIMER_KEEP_ALIVE,
            MS_TO_US(Connection->Settings.KeepAliveIntervalMs));
    }

So it fires only once the whole connection has gone quiet. That is the right rule for what it is — a timer that stops the connection going idle — and the wrong rule for keeping a path alive. A connection busy on one path pushes the timer out indefinitely while another path sits untouched, loses its NAT mapping, and is eventually abandoned by the peer.

Changes

A separate timer with its own setting, which nothing resets.

PathKeepAliveIntervalMs (default 0, disabled) is how long a path may go without sending before it gets a PING. It is counted per path, from what that path carried:

• QUIC_PATH gains LastSendTimeUs, stamped in QuicPacketBuilderSendBatch.
• QuicConnPathKeepAliveTimerUpdate sets SendKeepAlive on every path idle for the full interval, then arms QUIC_CONN_TIMER_PATH_KEEP_ALIVE for whichever path comes due next. A path that is sending on its own never gets a redundant PING, and the timer never wakes earlier than it has to.
• Armed when the handshake completes — the earliest point 1-RTT keys exist, which QuicSendPathKeepAlives needs — and on SetParam. Cancelled when the interval is 0 or the connection closes.

QuicConnProcessKeepAliveOperation goes back to a plain QUIC_CONN_SEND_FLAG_PING. KeepAliveIntervalMs means "keep the connection alive" again; keeping the paths alive is now the other setting's job. QuicSendPathKeepAlives from #74 is unchanged and serves the new timer.

QUIC_CONN_TIMER_PATH_KEEP_ALIVE is appended at the end of QUIC_CONN_TIMER_TYPE so the existing timer codes keep their values for anything decoding traces.

Testing

New Basic/WithFamilyArgs.PathKeepAlive in PathTest.cpp, registered in MsQuicTests.h, quic_gtest.cpp and winkernel/control.cpp. It brings up a two-path connection with no connection keep alive on either side and the MTU pinned so discovery cannot contribute traffic, then asserts both paths carry client→server datagrams over a 600ms window. Every datagram the server sees in that window is a keep alive. Removing the arming call flips it to failure:

FirstPathCounter.Count >= Expected not true
[  FAILED  ] Basic/WithFamilyArgs.PathKeepAlive/0

The "not reset by connection activity" half is not asserted, only measured. With a server keep alive of 20ms holding the connection busy, the path keep alive still fired 4 times in the window; emulating the old behaviour by re-arming the new timer from QuicConnResetIdleTimeout dropped that to 0 — the bug this change is about. It cannot become an assertion because QuicConnChoosePath picks a random active path per send, so under load neither path stays quiet enough for a datapath hook to tell keep alives from ordinary traffic.

Sweep	Result
*Multipath*:*Path*:*Migration*:*UnconnectedSocket*:*KeepAlive*	109 tests pass
*Basic*:*Datagram*:*Receive*:*Recv*	624 tests pass
PathKeepAlive × 6 repeats	pass
msquiccoretest --gtest_filter=*Settings*	14 pass, 3 skipped (pre-existing)
cargo test --features preview-api	13 pass

No compiler warnings.

Documentation

docs/Settings.md gains PathKeepAliveIntervalMs, and the KeepAliveIntervalMs row now says it is reset by connection activity — the distinction between the two.

The Rust bindings are updated: src/rs/settings.rs gains the setter and linux_bindings.rs was regenerated with cargo build --features overwrite. win_bindings.rs cannot be regenerated on Linux, so the identical hunks were applied by hand; the two diffs match line for line. The C# bindings were not updated — they need their generator re-run, and are already missing several fork settings.

[codecov]

Codecov Report

❌ Patch coverage is 95.65217% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/core/connection.c	96.42%	1 Missing ⚠️
src/core/settings.c	93.33%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!