path-spec.txt: mechanisms for detecting down network are redundant?
From path-spec.txt 2.4.5:
Clients assume that they have had network connectivity loss if a circuit times out and have received no cells or TLS handshakes since that circuit began. Clients then temporarily stop counting timeouts until network activity resumes (ie: until a TLS handshake completes or a cell arrives at the client). To detect changing network conditions, clients keep a history of the timeout or non-timeout status of the past 'cbtrecentcount' circuits (20 circuits) that successfully completed at least one hop. If more than 90% of these circuits timeout, the client discards all buildtimes history, resets the timeout to 'cbtinitialtimeout' (60 seconds), and then begins recomputing the timeout.
So as I understand it, we only count a timeout if two conditions apply:
- We have received network activity since the circuit launched.
- The circuit has completed at least one hop successfully.
But it seems to me that these two conditions are redundant, and we can just ignore the first: If the circuit has completed one hop successfully, then we received a create cell, and so the first condition will always be true if the second condition is true.
@mikeperry, am I reasoning through this correctly?