The intent of the idle timeout was to have that reflect *endpoint* policy. That is, it is independent of path.
It's certainly very interesting to consider what you might do about paths and keep-alives (or not). But that's a separable problem. Having a way for endpoints to share their information about timeouts might work, but I worry that that will lead to wasteful keepalive traffic. How would we ensure that keepalives are not wasteful? Is there a better way, such as a quick connection continuation? On Wed, Jul 24, 2024, at 11:24, Lucas Pardue wrote: > 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
