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