Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Oct 2015 10:19:27 -0700
From:      hiren panchasara <hiren@strugglingcoder.info>
To:        transport@FreeBSD.org
Subject:   Re: Setting congestion window on loss detection
Message-ID:  <20151012171927.GB92230@strugglingcoder.info>
In-Reply-To: <20151007195445.GC42742@strugglingcoder.info>
References:  <20151007195445.GC42742@strugglingcoder.info>

next in thread | previous in thread | raw e-mail | index | archive | help

--Fba/0zbH8Xs+Fj9o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.html
>=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 dupack=
s.
> 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?

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:

cwnd =3D min(cwnd, FlightSize)

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".

(I am not very familiar with linux code so please correct me if that's
not the case.)

Basically, I think any of these approaches is better than what we have in
the tree right now.

Cheers,
Hiren

--Fba/0zbH8Xs+Fj9o
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQF8BAABCgBmBQJWG+ucXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4
QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lF/AH/35US0f2QyjOIvJFR/32gjGG
d63SvM0t+jE9qcDQ4VlS7nPAfIVVs/noJfOk4EP1aJGnIpLSsok03iME+hoHHRX3
gJQY6AL956buoViFwdmlETXxznpbFHYnKofcEr14InrorjM6QJxv8ddezsapk8oa
ggwS+ytRqV813x8PotZ88zJk1X8k9KtE6Quy3Rf0SIz6u60yHPg2mcAQjNo/3I6r
srAboh42pbP/MMn35IPY8b/046n7ZhtPOEBgau1COyztAzWiKoe/4Bxj+jWF+iae
9NALXqEM5mbJTDfw+iTEA9DJ7ncqkJg3MOSBTG22Gq7aiHuiLY2eQlVcrwhWr/U=
=J3iC
-----END PGP SIGNATURE-----

--Fba/0zbH8Xs+Fj9o--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151012171927.GB92230>