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

[Martin Thomson <[e-mail]>]

Here's the example: Idle timeout is 10s.  You send a packet and subsequently receive an ACK at t=0.  You send a new message at T=10-sRTT.  You are now no longer idle, but the message you sent is going to arrive at the peer too late with ~50% probability of arriving before the idle timeout fires on their end.  During that last sRTT (and maybe a little before), you have a very good chance of not keeping the connection alive, but you will persist nonetheless and what will happen is that requests will fail.  The worst thing is that requests will fail in unrecoverable ways.

It's very clear that you don't want to count an RTO here.  A dead path is a common reason that you are hitting an RTO and restarting the idle timer just makes detecting the dead path that much harder (if not impossible as Subodh discovered).

I suspect that you want proof of life - that is, packets inbound - and to only rely on that.  You probably also need some advice about avoiding idle timeout by doing a liveness check once you reach `idle_timeout-sRTT-n*rtt_var` for some value of `n` that you tune based on your tolerance toward losing the messages you are about to send (for an idempotent message, `n` might be zero, for instance).

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