Re: [quicwg/base-drafts] Idle timeout needs more description and a recommendation (#2602)

[Jana Iyengar <[e-mail]>]

The recommendation is not for how long an endpoint is willing to wait, but a default recommendation for general purpose QUIC implementations. We have default recommendations in both the transport and the recovery draft based on best known practices. My suggestion for using 30 seconds as the default is based on GQUIC experience.

The min() thing is important IMO. Again, this is not a requirement, but keeping and trying a connection _after_ you believe the peer to have closed it potentially wastes an RTT.  HTTP connections using TCP do this all the time, and incur an RTT of delay. I'm not suggesting that we don't accommodate implementations that want to keep connections open for past the timeout period, but it's worth explicitly noting the cost of using a potentially dead connection. For an unconstrained implementation, what value do you see in continuing with a connection after it is likely to have been discarded by the peer?

Endpoints need to keep not only NAT bindings alive but also potentially QUIC state at the peer alive. If a server is taking time to generate a response and there is a risk of the idle timeout closing the connection  before the server sends a response. The application (HTTP) knows this, and is expected to send PINGs to keep the connection open, but without knowledge of the idle timeout at the peer, it has to guess how often to send a PING.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2602#issuecomment-481494142