in case of resetting the t_dupacks in tcp_input.c

[hiren panchasara]

On 09/22/15 at 10:42P, ??? wrote:
> Hi,
> 
> 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.

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-net/attachments/20150921/46d15e99/attachment.bin>