Connected: An Internet Encyclopedia
RFC 1323 - B.1 System Crash with Loss of State

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1323
Up: APPENDIX B: DUPLICATES FROM EARLIER CONNECTION INCARNATIONS
Prev: APPENDIX B: DUPLICATES FROM EARLIER CONNECTION INCARNATIONS
Next: B.2 Closing and Reopening a Connection

### B.1 System Crash with Loss of State

TCP's quiet time of one MSL upon system startup handles the loss of connection state in a system crash/restart. For an explanation, see for example "When to Keep Quiet" in the TCP protocol specification [Postel81]. The MSL that is required here does not depend upon the transfer speed. The current TCP MSL of 2 minutes seems acceptable as an operational compromise, as many host systems take this long to boot after a crash.

However, the timestamp option may be used to ease the MSL requirements (or to provide additional security against data corruption). If timestamps are being used and if the timestamp clock can be guaranteed to be monotonic over a system crash/restart, i.e., if the first value of the sender's timestamp clock after a crash/restart can be guaranteed to be greater than the last value before the restart, then a quiet time will be unnecessary.

To dispense totally with the quiet time would require that the host clock be synchronized to a time source that is stable over the crash/restart period, with an accuracy of one timestamp clock tick or better. We can back off from this strict requirement to take advantage of approximate clock synchronization. Suppose that the clock is always re-synchronized to within N timestamp clock ticks and that booting (extended with a quiet time, if necessary) takes more than N ticks. This will guarantee monotonicity of the timestamps, which can then be used to reject old duplicates even without an enforced MSL.

Next: B.2 Closing and Reopening a Connection

Connected: An Internet Encyclopedia
RFC 1323 - B.1 System Crash with Loss of State