in case of resetting the t_dupacks in tcp_input.c
hiren at strugglingcoder.info
Tue Sep 22 06:43:13 UTC 2015
On 09/22/15 at 10:42P, ??? wrote:
> I have a question that reset a dupack count in tcp stack.
> My company's product was tested on freebsd 10.
> As far as I know The fast retransmission is triggered when the receiver is
> received 3 dup acks.
> Why is the t_dupack value reset, if we happen to get data or a window
> update along with a duplication ack?
> I checked openbsd and netbsd.
> The t_dupack is not reset on the netbsd, if it receive ack that
> get a window update(changed) along with a duplication ack.
> The t_dupack is reset on the openbsd, if it receive ack that
> get a window shrink along with a duplication ack.
> I don't know why the t_dupack is reset, if to get a window update.
> I think Just it is skipped(is not reset),
> if we receive the ack that is window update. like netbsd.
> could you explain about this?
Your assessment is correct. RFC 5681 doesn't seem to suggest that the
3 dupacks have to be consecutive but FreeBSD does. So, whenever we get a
duplicate ack that doesn't follow the definition, we reset it to 0.
IMO, NetBSD implementation is correct in this regard. I and a bunch of
other developers are looking into fixing this the right way.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 603 bytes
Desc: not available
More information about the freebsd-net