Date: Mon, 21 Sep 2015 23:43:11 -0700 From: hiren panchasara <hiren@strugglingcoder.info> To: ??? <yongmincho82@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: in case of resetting the t_dupacks in tcp_input.c Message-ID: <20150922064311.GA29193@strugglingcoder.info> In-Reply-To: <CA%2BVsu-%2BDDTaRjbwxSktJL4vnHTeoLMzQ9ygAhkRy=LULPw8aFQ@mail.gmail.com> References: <CA%2BVsu-%2BDDTaRjbwxSktJL4vnHTeoLMzQ9ygAhkRy=LULPw8aFQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 09/22/15 at 10:42P, ??? wrote: > Hi, >=20 > 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? >=20 > 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. >=20 > 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.=20 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 --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJWAPh8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lNXIH/35pkslDLjdX1HmrctJs2fEd SfGYgZEFm5vfkCK+OM9bqZDKPCBUj7gEA8aFKeZfBJ8sz80cxCdI+z+2Zn0/Cwdk q7v6+Y5wxPCV3QnXDtNtQLzM8WQxiq/7IBz7TKXdW26LKjCSK252M+gH7lGg9kn0 z0d+MmWhG61tkaWtf0holYJEG8P/WI3kREh4QGPtmhPJUVXV+sKBc9796yvZKV1+ 8x0nGYQZlTHOLyQlNqFseN8L0x4okaPqmgvmpM1+w4ZEhbofIzKcdpXUPxEesJKf J5nT0MWcXdvJWJ7ht307sAAnAQ9uo1Xi0xl1SBi/rZiwyO+8Xz7OW7jGL8R1Cmw= =oUej -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150922064311.GA29193>