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

[Martin Thomson <[e-mail]>]

The requirement to distinguish new vs. retransmitted is hard.  I think that last received is simple and effective enough - any data you send will be acknowledged, and retransmitted if it is not, so the start of the timer is close enough to the point that activity ceases.

The other thing to consider here is whether we allow the idle timeout to be asymmetric.  That is, it is in effect a statement of "if I don't see a packet from you in N seconds, I will drop state for this connection."  On face value, that doesn't help, because the peer with the shorter timer ultimately determines when the connection goes away, but it could allow - for example - a client to make a request without having to worry about a server's idle timeout.  Say the client has a 10s timeout and the server has a 30s timeout.  Rather than having to probe to see if the connection is still live when the connection gets close to 10s of idleness, the client can just send a request because it knows that the server will still be there (the network path, less so, but it's wise to keep that separate from this).

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