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

hiren panchasara hiren at strugglingcoder.info
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.

Cheers,
Hiren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-transport/attachments/20151029/b7cdbf30/attachment.bin>


More information about the freebsd-transport mailing list