Maintaining dupack counter per hole (was: The trouble with sack..)

hiren panchasara hiren at
Fri Oct 30 06:24:26 UTC 2015

(Something Randall and I discussed today)

On 10/07/15 at 12:17P, Randall Stewart via freebsd-transport wrote:
> 3) When we have more than one hole the goal of SACK was to retransmit every time that
>     a hole had 3 dup-acks so that one could recover multiple blocks that were lost. We just
>     plain don?t track dup-acks per hole. We do continue to count, but we will wait to retransmit
>     anything until after we have drained 1/2 the data in flight from the network at a minimum. And only then
>     do we start incrementing cwnd (remember we crashed it to 1 MTU) so that we can retransmit. There
>     may be some other twists in the code that we are missing but this is what we believe (this could could
>     probably win the C obfuscation contest if someone were willing to enter it :-D)

Wondering if we can add this dupack counter in struct sackhole {} and
every time we process acks with sack in tcp_sack_doack(), we increment
this counter if the same hole appears again. And retransmit it on (or
after?) 3rd dupack.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <>

More information about the freebsd-transport mailing list