QUIC idle timeouts and path idle timeouts

[Lucas Pardue <[e-mail]>]

Hi folks,

Wearing no hats.

There's been some chatter this week during IETF about selecting QUIC idle timeouts in the face of Internet paths that might have shorter timeouts, such as NAT.

This isn't necessarily a new topic, there's past work that's been done on measurements and attempts to capture that as in IETF documents. For example, Lars highlighted a study of home gateway characteristics from 2010 [1]. Then there's RFC 4787 [2], and our very own RFC 9308 [3]

There's likely other work that's happened in the meantime that has provided further insights.

All the discussion got me wondering whether there might be room for a QUIC extension that could hint at the path timeout to the peer. For instance, as a server operator, I might have a wide view of network characteristics that a client doesn't. Sending keepalive pings from the server is possible but it might not be in the client's interest to force it to ACK them, especially if there are power saving considerations that would be hard for the server to know. Instead, a hint to the peer would allow it to decide what to do. That could allow us to maintain a large QUIC idle timeouts as befitting of the application use case, but adapt to the needs of the path for improved connection reliability. 

Such an extension could hint for each and every path, and therefore a benefit to multipath, which has some addition path idle timeout considerations [4].

Thoughts?

[1] - https://dl.acm.org/doi/10.1145/1879141.1879174
[2] -  https://www.rfc-editor.org/rfc/rfc4787.html
[3] - https://www.rfc-editor.org/rfc/rfc9308.html#section-3.2
[4] - https://www.ietf.org/archive/id/draft-ietf-quic-multipath-10.html#name-idle-timeout