Hey Marten, Excellent question. I tried to cover some high level example use cases in the I-D but lets throw some more concrete (although hypothetical ones) around on the list. I do agree the mechanism is a little more complex than I would have first liked but it made sense to me when thinking about some of the clients and servers I have experience with.
Use case 1: A server wishes to drain the connection gracefully. For example, an HTTP/3 server issues a GOAWAY, no new requests can be made per Section 5.2 of RFC 9114 [1]. There's also this sentence in that section: > Once all accepted requests and pushes have been processed, the endpoint can > permit the connection to become idle, or it MAY initiate an immediate closure > of the connection. In my experience, the configuration of idle timeouts tend to be aimed at the "active connections" trying to do things, rather than be draining. Some clients, such as those on mobile devices, set quite long idle timeouts to avoid unnecessarily waking up the radio. Picking a further smaller value in the draining state could avoid needing to wake them up to tell them to close when nothing actually happened on a draining connection (for example, waiting on an upstream to generate responses that might never happen). Use case 2: Adapting the idle timeout specifically to application workload. Application protocols such as HTTP/3 enable many kinds of interation models on the top, such as the plethora of extended CONNECT protocols including TCP, IP, UDP and WebTransport. When operating a server, it is not always clear what a given connection might primarily be used for. While some deployment models might use domain sharding to isolate application workloads, there are various benefits that arise from not doing that and coalescing connections. Allowing the idle timeout to adapt up or down, based on how an application protocol intends to drive the QUIC transport, seems a powerful feature and something more in line with some of the flexibility we afford to other transport features (e.g. flow control). For example, a MoQ broadcast over WebTransport may have anticipated quiet periods, and being able to increase the idle timeout to avoid unnecessary chatter could be nice Use case 3: Adapating idle timeout based on layer 7 peer trust. While TLS provides authentication (and lets not forget mutual TLS), there are numerous layer 7 approaches to establishing further auth on top of it. For instance, we're seeing emerging uses of HTTP signatures [2] for identifying different types of clients - moving away from IP-based identification. See the Web Bot Auth WG [3] for some more examples. It seems in the realm of possibility that an HTTP/3 server might wish to extend an idle timeout to "trusted" clients that are able to authenticate themselves post handshake. This would allow conservative defaults for less-trusted traffic. Use case 4: Planned suspend/resume type activities. I'm stretching my experience a little here, but I have heard a few cases where folks are looking to leverage QUIC in environments where the concept of suspend/resume can occur. Either something like a VM being migrated in a DC, or a mobile device deterministically entering some area of restricted connectivity. Session resumption can go a long way for such cases, while I've seem some other design proposals for QUIC extensions to address more advanced needs [4]. However, maybe the simplest thing is to just ask your peer if it wouldn't mind the connection picking a larger idle timeout on the active connection for a while to avoid some hassle during the disturbance, before resorting to the steady-state value previously negotiated. Cheers, Lucas [1] - https://datatracker.ietf.org/doc/html/rfc9114#connection-shutdown [2] - https://datatracker.ietf.org/doc/html/rfc9421 [3] - https://datatracker.ietf.org/group/webbotauth/about/ [4] - https://datatracker.ietf.org/doc/draft-banks-quic-cibir/ On Wed, Nov 26, 2025, at 10:47, Marten Seemann wrote: > Hi Lucas, > > First of all, can you tell us a little bit more about the use case for > changing the idle timeout? In which situations do you envision this to be > useful? > > After reading through the draft, I was wondering if the negotiation mechanism > could be simplified. In RFC 9000, the idle timeout is calculated as the > minimum value advertised by the client and by the server during the > handshake. You could define a new frame that updates this advertisement: the > new idle timeout would now be the minimum of the peer's value and the new > value sent in the frame. > > Cheers, > Marten > > On Fri, 14 Nov 2025 at 03:41, Lucas Pardue <[email protected]> wrote: >> __ >> Hi folks, >> >> Based on some hallway conversations at IETF 124, I realised that one of >> properties of QUIC connections that is hard to tweak during its lifetime is >> the idle timeout. As we see more use cases emerge for the protocol, it >> seemed like there _might_ be some opportunity to benefit from dynamic >> adjustments. >> >> I'm not wedded to the technical design in 00, and it opens a few questions >> that we have been able to ignore so far. >> >> If you think this is something that might be useful, I'd like to hear more. >> >> Cheers >> Lucas >> >> ----- Original message ----- >> From: [email protected] >> To: Lucas Pardue <[email protected]> >> Subject: New Version Notification for >> draft-pardue-quic-idle-timeout-update-00.txt >> Date: Thursday, November 13, 2025 19:31 >> >> A new version of Internet-Draft draft-pardue-quic-idle-timeout-update-00.txt >> has been successfully submitted by Lucas Pardue and posted to the >> IETF repository. >> >> Name: draft-pardue-quic-idle-timeout-update >> Revision: 00 >> Title: QUIC Idle Timeout Update >> Date: 2025-11-13 >> Group: Individual Submission >> Pages: 8 >> URL: >> https://www.ietf.org/archive/id/draft-pardue-quic-idle-timeout-update-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-pardue-quic-idle-timeout-update/ >> HTML: >> https://www.ietf.org/archive/id/draft-pardue-quic-idle-timeout-update-00.html >> HTMLized: >> https://datatracker.ietf.org/doc/html/draft-pardue-quic-idle-timeout-update >> >> >> Abstract: >> >> QUIC supports an idle timeout for connections, which can be >> negotiated once during the connection handshake. This document >> defines QUIC extension frames that permit either endpoint to initiate >> an update to the idle timeout value. >> >> >> >> The IETF Secretariat >> >> >> >>
