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
pgp85xxByLBZB.pgp
Description: PGP signature
