One of the ways to detect loss is to count dupacks till they reach decided
threshold (3 in our case).
dupack counting/incrementing is incorrect in a couple of ways:
- We reset dupack counter to 0 when certain conditions are not met and if an old ack arrives.
- When SACK is present, if the ack has window change, we don't consider it as a dupack.
Here is what this change is trying to bring from rfc5681 and rfc6675:
a) th_ack < snd_una --> ignore it completely
b) th_ack == snd_una, window == old_window --> increment
c) th_ack == snd_una, window != old_window, change_in_sacked_bytes == 0 --> do
d) th_ack == snd_una, window != old_window, change_in_sacked_bytes != 0 -->
change_in_sacked_bytes is a new addition to sackhint. It keeps track of change
reported via SACK info. (This will be reused in PRR Proportional Rate Reduction
work I am doing.)