Date: Tue, 11 Oct 2016 23:28:10 -0700 From: hiren panchasara <hiren@strugglingcoder.info> To: Randall Stewart <rrs@netflix.com> Cc: FreeBSD Transports <transport@FreeBSD.org>, lstewart@FreeBSD.org Subject: Re: Exiting from loss recovery Message-ID: <20161012062810.GO20670@strugglingcoder.info> In-Reply-To: <1BC53E8D-08B9-4C4C-8E7B-6346CA83F66E@netflix.com> References: <20161007002211.GO50669@strugglingcoder.info> <1BC53E8D-08B9-4C4C-8E7B-6346CA83F66E@netflix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--s9pXJW6w71JX4l3T
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Randall,
I am a bit confused. :-)
Can you please clarify what you mean here? Are you
talking about=20
cc_ack_received(tp, th, nsegs, CC_ACK); ?
Probably I am being a bit slow here but any explanation around how
stretch acks can be a problem here would be great. :-)
Thanks,
Hiren
On 10/10/16 at 09:56P, Randall Stewart wrote:
> Hiren:
>=20
> I have a bit of experience now with this code.
>=20
> If you exit recovery where Lawerence has marked, then when you go
> down a few lines and credit the ack to the cwnd it can be a very
> large ?stretch? ack.. making cwnd spike up incorrectly by standard
> new-reno terms?=20
>=20
> If you do move exit recover to there, you probably need to have a limit
> on how big the cwnd can move? i.e. some sort of segment limit.
>=20
> R
>=20
> > On Oct 6, 2016, at 8:22 PM, hiren panchasara <hiren@strugglingcoder.inf=
o> wrote:
> >=20
> > In tcp_do_segment():
> >=20
> > /*
> > * If the congestion window was inflated to account
> > * for the other side's cached packets, retract it.
> > */
> > if (IN_FASTRECOVERY(tp->t_flags)) {
> > if (SEQ_LT(th->th_ack, tp->snd_recover)) {
> > if (tp->t_flags & TF_SACK_PERMIT)
> > tcp_sack_partialack(tp, th);=20
> > else
> > tcp_newreno_partial_ack(tp, th);=
=20
> > } else=20
> > cc_post_recovery(tp, th);=20
> > }
> >=20
> > Here, if we get an ack that marks recovery from loss i.e. >=3D
> > snd_recovery, we call cc_post_recovery() which in-turn calls CC specific
> > post_recovery routine. But we don't reset TF_FASTRECOVERY |
> > TF_CONGRECOVERY flags by calling EXIT_RECOVERY()=20
> >=20
> > Later in the code we do this check again in 'process_ACK:'
> >=20
> > /* XXXLAS: Can this be moved up into cc_post_recovery? */
> > if (IN_RECOVERY(tp->t_flags) &&
> > SEQ_GEQ(th->th_ack, tp->snd_recover)) {
> > EXIT_RECOVERY(tp->t_flags);
> > }
> >=20
> > And as it can be seen, Lawrence marked it as something that could
> > possibly be done here and at the end of cc_post_recovery().=20
> >=20
> > So, should we do it? i.e call EXIT_RECOVERY() at the end of
> > cc_post_recovery() and remove the block from 'process_ACK' section? or
> > there is something subtle I am not seeing?
> >=20
> > Cheers,
> > Hiren
>=20
> --------
> Randall Stewart
> rrs@netflix.com
> 803-317-4952
>=20
>=20
>=20
>=20
>=20
--s9pXJW6w71JX4l3T
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQF8BAABCgBmBQJX/df2XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4
QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lzssH/j6iDwkhb5ROOglhGY3leuKG
MlI2x12+aTvZ7I4fLHtrvpm1kPbxxXbtXEkueaYLW+J/Cq0GnmZg+cmUQg5gg73t
u8P3DvU1/xGQsLZW/ij3diyfiNDiLUt4SkudTiHUQI72pkn0eY2QUo6C+HcMcgBY
lg1MmgR4QKor68da1c+NFmZ7lfpX7NzpBV8pTEhxlWzU2zUKePYlvTbp75MPwtEI
2urB1tA2uEbPpflDLAU5hl3EpqaOkMbxRm3hscbkDnW1aKtUjPaapRFTkQFEjrjp
4asQeRmch0Rt/7QJhwPt3ffFUazc78QNZn+A2A6Obw9RM3CoJQDtLSkG7sFXRE4=
=R6XX
-----END PGP SIGNATURE-----
--s9pXJW6w71JX4l3T--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161012062810.GO20670>