From owner-freebsd-net@freebsd.org Tue Sep 22 06:43:13 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B823A038C5 for ; Tue, 22 Sep 2015 06:43:13 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 894371DBE for ; Tue, 22 Sep 2015 06:43:13 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 08A7FD133E; Mon, 21 Sep 2015 23:43:12 -0700 (PDT) Date: Mon, 21 Sep 2015 23:43:11 -0700 From: hiren panchasara To: ??? Cc: freebsd-net@freebsd.org Subject: Re: in case of resetting the t_dupacks in tcp_input.c Message-ID: <20150922064311.GA29193@strugglingcoder.info> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 06:43:13 -0000 --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--