Re: [quicwg/base-drafts] Idle timeout interaction with RTO (#1429)

[ianswett <[e-mail]>]

One fairly good definition of the start of idleness is the max(time of last received packet, time of last sent packet after a packet was received).  The latter is there to ensure you don't idle timeout immediately after sending a request.  

Though if you're RTOing packets you're not technically idle, there's no proof the connection is still alive, so extending the idle timeout when sending timer based retransmissions is quite dangerous.

There is some inherent asymmetry between when you should no longer send new data vs when you should stop receiving data.  Ideally you'd continue processing incoming data for at least an RTT longer than you would send new data.

There are definitely some potential benefits in timing out the connection earlier when you believe it's dead, such as after 5RTOs or another criteria, but I'd be hesitant to recommend a uniform approach to dead connection detection for all applications and circumstances.  I think H2 commonly bundles a ping with new requests and then there's a subsequent timeout?  In QUIC, the PING wouldn't be necessary, since the request gets acknowledged.

-- 
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/1429#issuecomment-396311683