Date: Thu, 3 Sep 2015 10:53:13 -0700 From: hiren panchasara <hiren@strugglingcoder.info> To: Lawrence Stewart <lstewart@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: Value of congestion window (cwnd) when loss is detected Message-ID: <20150903175313.GS68814@strugglingcoder.info> In-Reply-To: <20150903161651.GQ68814@strugglingcoder.info> References: <20150903005405.GN68814@strugglingcoder.info> <55E82B59.6000202@freebsd.org> <20150903161651.GQ68814@strugglingcoder.info>
next in thread | previous in thread | raw e-mail | index | archive | help
--H5pgEA8DvTwLpheO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 09/03/15 at 09:16P, hiren panchasara wrote: > On 09/03/15 at 09:13P, Lawrence Stewart wrote: [skip] > >=20 > > You want to read up about window inflation during fast recovery in RFC > > 5681 followed by 3782, and then consult Stevens vol 2 to understand how > > variables are used for different purposes depending on connection state > > and which code path was taken (something I greatly dislike and would > > love to change one day). Here is my understanding of these rfcs: RFC 5681: 3.2. Fast Retransmit/Fast Recovery When we detect loss: 2. When the third duplicate ACK is received, a TCP MUST set ssthresh to no more than the value given in equation (4). When [RFC3042]is in use, additional data sent in limited transmit MUST NOT be included in this calculation. ssthresh =3D max (FlightSize / 2, 2*SMSS) <-- equation (4). In my example, ssthresh =3D max (14480 / 2, 2*1448) =3D 7240. i.e. 5 packets 3. The lost segment starting at SND.UNA MUST be retransmitted and cwnd set to ssthresh plus 3*SMSS. This artificially "inflates" the congestion window by the number of segments (three) that haveleft the network and which the receiver has buffered. cwnd =3D (ssthresh + 3*SMSS) In my example, cwnd =3D 7240 + 3*1448 =3D 11584, i,e, 8 packets RFC 3782: We either do sack based recovery *or* newreno based recovery. And we do sack based when TF_SACK_PERMIT is present. So I don't think this comes into play. Please correct me if that is not the case. Stevens vol 2: sshthresh: "When t_dupacks reaches 3 ( tcprexmtthresh ), the value of snd_nxt is saved in onxt and the slow start threshold ( ssthresh ) is set to one-half the current congestion window, with a minimum value of two segments." snd_cwnd: The congestion window is set to the slow start threshold plus the number of segments that the other end has cached. By cached we mean the number of out-of-order segments that the other end has received and generated duplicate ACKs for. These cannot be passed to the process at the other end until the missing segment (which was just sent) is received. So, according to this, sshthresh itself is set pretty high i.e. cwnd/2. And, snd_cwnd =3D sshthresh + cached packets at the other end. In my example, when server realizes loss, cwnd is 17377 i.e. 12 packets. Half of that is 6 packets. And cached packets is 2 because the dup acks we got were for 'ack 2897'. So, according to stevens, snd_cwnd should have been 6+2 =3D 8 packets. Which matches up to what RFC 5681 suggests. Does this look reasonable? Cheers, Hiren --H5pgEA8DvTwLpheO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJV6IkIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lKxkH/Al/p8UkvNMD6jzWMPlP57I+ 6d6u5kAe+gPnvDxAqQtuYgmirCb60YkXLBw7c+xoa39ThMsNx+R336ftRWYIhw8B Jjvwih8f6ZLZmvr+BQg5Hkywt1V9PO8bOtKMZ+kcLuGB75RWxuKljp51TGLFf6lZ N+/u0zPgTTyReWQNV3OI3EK5E8T9udBpyUWU6uYUDODaatvyMSOZJBKQAsvE0WEh kBAyh2p2XOGv+eCHGxszvHp65JnLZ3kSQK46ZhLaNRa2wnfpqKwSdFaqDFZG4DUm AJBhfMHUEHPkwkCDxnc+lCOCpWsfLkbYRpPMj2DlH71vukwjDVAFRsGDTCQkt1Q= =K0QQ -----END PGP SIGNATURE----- --H5pgEA8DvTwLpheO--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150903175313.GS68814>