RFC6675 allows for a less conservative estimate of
the pipe size (data presumed still in flight and not
lost). Basically, when the SACK scoreboard indicates
that at least (DupThresh-1)*SMSS + 1 bytes were
received by the client, or DupThresh number of SACK
blocks beyond had been returned, it is reasonable
to assume this byte to have been lost by the network.
Together with PRR (RFC6972) this allows a sender to
retransmit presumed lost packets faster, and loss
recovery to complete earlier.
This implementation first tracks all the unacknowledged
bytes in the SACK scoreboard, by accounting any change
during the regular scoreboard updating.
When traversing the scoreboard for right to left to
update it with any received new SACK blocks, the
number of discontinous holes, as well as the bytes
in between holes and holes themselves are summed up.
Once the required threshold of positively sacked
bytes, or discontinous sack ranges is reached, the
remaining holes in the scoreboard are declared lost
for the purpoes of calculating pipe.
All that additional accounting happens during normal
SACK scoreboard updates - at most, DupThesh-1 additional
holes have to be processed.