exerpt from Dr. Dohy Hong's observation:
------------------------------------------------------
In case of On-Off traffic for TCP, at the end of the
file size to transmit, with TCP/SACK1, we discovered that
in case of multiple losses, it can enter to timeout
anormally.

It seems quite generic and lead to higher to rate for
on-off traffic.

In the bug we saw, no retransmitted packet is lost.
For traces: lauch the script, then observe as follow:

plot [2595:2604] 'f1' w linesp,'ploss' u 1:3 w i (gnuplot)

In "trace" file, you'll see that pkt 79955 and 79974 are lost
at (2598.145 and 2598.297). Then 79955 retransmitted roughly
500 ms after: that's ok.
Then 15 SACK blocs showing the hold 79955 arrives, followed by
26 SACK blocs showing holds 79955 and 79974.

The problem is, in this case, because of end of file, when loss
occur, inflight packets = 46 (and cwnd = max_cwnd = 60).
With the computation of pipe (in sack, cwnd is divided by 2 and
then don't move until end of FR), it should have retransmit PKT
79974 when about 16-17 DUPs are received. Here, it does not
react.

I also played, just increasing the file size (to avoid border effect
of end of file), I saw that the problem disapeared (to keep the same
loss event, I did it only for this file size).

So I suspect a wrong computation of pipe with the end of file
border effect... or something this kind.

In this scenario, losses are sampled randomly on the link
(loss_module) and there are no buffer overflow.

I also attached "f1" file to verify first that you'll get the same
output (hope random seed is same... should be ok for linux machine).
I also attached "trace-sample", filtered from "trace" file.