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

[Martin Thomson <[e-mail]>]

I disagree with this.  In total, but for various reasons.

Endpoints have their own rules about how long they are willing to wait, so any recommendation is a bad idea.

The min(client, server) thing is not necessary.  You might note that this is a natural consequence of the design, but this is a unilateral thing.  If you want to wait longer, you can.  This is particularly important in cases where connections are garbage-collected rather than reaped on a timer.  In those cases, idle timeouts can be much longer on one end than the other if the short timer is GC'd.  The endpoint that does GC might hold the connection alive much longer, and even initiate new activity on that connection well after its advertised timeout.

This can be different to what endpoints might choose to do about keep NAT bindings alive.  Keepalives are sent to keep bindings alive on paths and [we already have text on that](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#frame-ping).  Paths are not connections.

-- 
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-481490843