Re: QUIC idle timeouts and path idle timeouts

[Martin Thomson <[e-mail]>]

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