From owner-freebsd-transport@freebsd.org Sat Oct 31 00:33:25 2015 Return-Path: Delivered-To: freebsd-transport@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 82FC8A22E3E for ; Sat, 31 Oct 2015 00:33:25 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 672A21AB1 for ; Sat, 31 Oct 2015 00:33:25 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: by mailman.ysv.freebsd.org (Postfix) id 6527AA22E3D; Sat, 31 Oct 2015 00:33:25 +0000 (UTC) Delivered-To: transport@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 64BF8A22E3C for ; Sat, 31 Oct 2015 00:33:25 +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 51F5A1AB0 for ; Sat, 31 Oct 2015 00:33:24 +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 67AD510B715 for ; Fri, 30 Oct 2015 17:33:24 -0700 (PDT) Date: Fri, 30 Oct 2015 17:33:24 -0700 From: hiren panchasara To: transport@FreeBSD.org Subject: Re: Setting congestion window on loss detection Message-ID: <20151031003324.GI5261@strugglingcoder.info> References: <20151007195445.GC42742@strugglingcoder.info> <20151012171927.GB92230@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="z3SYAdNKCFJcUCPa" Content-Disposition: inline In-Reply-To: <20151012171927.GB92230@strugglingcoder.info> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 00:33:25 -0000 --z3SYAdNKCFJcUCPa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 10/12/15 at 10:19P, hiren panchasara wrote: > On 10/07/15 at 12:54P, hiren panchasara wrote: > > Found this issue about a month ago and started a discussion on -net: > > https://lists.freebsd.org/pipermail/freebsd-net/2015-September/043249.h= tml > >=20 > > I feel this forum is a better place to discuss this further now. > >=20 > > Problem: We set cwnd to 1mss when we detect loss via arrivals of 3 dupa= cks. > > That is wrong as we severely underutilizing network capacity by doing > > so. > >=20 > > Next question is, what should we set cwnd to? > >=20 > > RFC6675 (TCP SACK) suggests following on detecting loss: > > ssthresh =3D cwnd =3D (FlightSize / 2) > >=20 > > RFC5681 (TCP Congestion control) suggest: > > ssthresh =3D max (FlightSize / 2, 2*SMSS) > > cwnd =3D (ssthresh + 3*SMSS) > >=20 > > (Here, FlightSize is bytes in flight.) > >=20 > > OR should we let whatever congestion control (CC) algo in control decide > > that value? >=20 > I also tried to look at what Linux does. It has PRR (Proportional Rate > Reduction) RFC 6937 (something I plan to work on after these initial > needed fixes/improvements) in place. Looking back pre-PRR code, linux > seems to be doing following: >=20 > cwnd =3D min(cwnd, FlightSize) >=20 > Here, cwnd in the equation is adjusted as per rate-halving > (draft-mathis-tcp-ratehalving-00) which says "the window is reduced by > sending one data segment for each two segments which are acknowledged". >=20 > (I am not very familiar with linux code so please correct me if that's > not the case.) >=20 > Basically, I think any of these approaches is better than what we have in > the tree right now. As suggested by Randall on the transport group call, I'd go ahead and see if following RFC6675 gives us any better results with different loss scenarios. Cheers, Hiren --z3SYAdNKCFJcUCPa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJWNAxUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lZ70H/0IV/XiFfGtpQpICrdL3J1lK iud16poakoUr1mXlGDXyy8XZpqd+aMF9YWM8o7RI8b3UNjFReInD8+Akc6PzYyVU 7bbLQoN+ZwVkRuALih3BXM6oJAA5IWsYOqm6dbhlktrkN46EuDiiUB/o6lvsC/Js fG2OZftBwpeVJyOTdlkjL/3H/JzgSuvHjVNqN2rwY8JnJeo4xT6mpgYZ9lgBo+PV nTFdX4tgeDEctaw4tM7K3Jl1U2mIZeAKrfICA1PyBD0KHPxFnnmO92+BKrSxln1i r4DNAW7IlmnVvAqXLqnl2wKbqrQa25fvgaWIqqpC38vO3c1MzPIrvxSEjYnSxGU= =q0PY -----END PGP SIGNATURE----- --z3SYAdNKCFJcUCPa--