Re: QUIC idle timeouts and path idle timeouts

[Martin Thomson <[e-mail]>]

On Mon, Sep 2, 2024, at 06:00, Ian Swett wrote:
> I think you're suggesting that a large server operator could try to 
> infer NAT timeouts for clients of different IP prefixes and communicate 
> that to the client as a suggested keepalive/ping timeout?  I'm curious 
> about how to infer NAT timeouts?  Our servers detect a dead connection, 
> but I'm not sure how to tell what the reason is and more specifically 
> the NAT timeout?  Sometimes devices just drop off the network.

Large server operators are already in a position where they can observe NAT timeouts.  They could unilaterally act on that information if they chose (a server can send a keepalive as easily as a client, even if the server might prefer not to).

I'm more concerned about the effect that more keepalives would have on the network.  For every connection that you keep alive long enough to have that connection be usable for the next request, there would be some (potentially much larger) number of keepalive messages sent that wasted battery and other resources to no end.


> As you may know, Chrome will send a PING as a keepalive after 15 
> seconds of idle only if there are outstanding requests (ie: hanging 
> GETs).  

We do similarly, though I believe that our number is based on the idle timeout rather than being purely arbitrary.  (The effect is usually the same; our default idle timeout is 30s and we scale that down by a factor of 2.)