Exercise 3: Why Check Retransmissions Twice, Not Once — Possible Solution
====================================================================

WHAT A SINGLE READING TELLS YOU
------------------------------
netstat -s's retransmission count is a cumulative total since the
counter was last reset - a single reading only tells you how many
segments have been retransmitted in total up to that moment, which
says nothing about whether retransmissions are actively happening now
or happened once, long ago, and stopped.

WHAT COMPARING TWO READINGS TELLS YOU
------------------------------
Per this chapter, "the absolute number matters less than the trend -
over 1,100 additional retransmitted segments in one minute... is a
real, active signal that packets are being lost somewhere on the
path, not just background noise." Taking a second reading a fixed time
later and comparing the difference converts a meaningless cumulative
total into a rate - segments retransmitted per minute - which is what
actually indicates whether loss is happening right now.

WHY THE RATE MATTERS MORE THAN THE TOTAL
------------------------------
A large total retransmission count on a server that's been running for
weeks could easily represent completely ordinary, historical network
hiccups spread out over a long period - not evidence of a current
problem. A large increase within one minute, specifically, is what
distinguishes an actively ongoing issue from an old, already-resolved
one, the same "total vs. currently active" distinction Chapter 3 drew
for swap usage.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains what a single cumulative reading can and can't tell you,
and explains specifically why comparing two readings over a known time
interval converts the count into a genuinely diagnostic rate, rather
than just saying "one reading isn't enough" without explaining what
the second one adds.