The loss of a retransmission during loss-recovery is currently an
event, that can only be recovered from in the base stack, by waiting
for a lengthy RTO, and then picking up from there with slow-start
again.

The theory of operation of this variant - which only works in
conjunction with SACK - is to remeber the snd_recover point
at the time, the last segment of a scoreboard hole is sent out.

Once snd_fack (the topmost right edge of a returned SACK block)
acknowledges the recovery point (snd_recover) - that is, a SACK
for a segment beyond snd_nxt at the time of entering loss-recovery,
the first window of loss recovery is over. Without additional loss,
all holes in the SACK scoreboard should have closed by that time
with successful retransmissions. Thus any remaining holes are
likely to be due to lost retransmissions.

Caveats:

• Extremely severe reordering of original and retransmitted packets

may cause similar observable SACK patterns.

• When the sender has no data to send beyond recovery point, which

is a not uncommon in request-response IO type exchanges, where TCP
often is application limited, the above heuristic will never trigger.
A more agressive variant of LRD could simply check when an octet
dupthresh*SMSS beyond the current hole is acknowledges (or the highest
outstanding, not-yet-acked octet, if no additional data is available
for sending), and restart the retransmission from the leftmost hole
at that point.

• This is work in progress
• The patch has been revived from code written against 8.0

Extensive Unit testing will be necessary, to validate no unexpected
or damaging behavior under severe reordering, extensive loss, ack thinning,
application limiting etc.