Date: Thu, 14 Nov 2019 17:32:08 +0100 From: Michael Tuexen <tuexen@freebsd.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r354708 - head/sys/netinet/cc Message-ID: <E39CDB15-9ECD-4DD5-8706-130B4E55DF3E@freebsd.org> In-Reply-To: <201911141628.xAEGS3QO052853@repo.freebsd.org> References: <201911141628.xAEGS3QO052853@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 14. Nov 2019, at 17:28, Michael Tuexen <tuexen@FreeBSD.org> wrote: >=20 > Author: tuexen > Date: Thu Nov 14 16:28:02 2019 > New Revision: 354708 > URL: https://svnweb.freebsd.org/changeset/base/354708 >=20 > Log: > For idle TCP sessions using the CUBIC congestio control, reset = ssthresh > to the higher of the previous ssthresh or 3/4 of the prior cwnd. I mixed that up. It should have been: This patch addresses a very common case of frequent application stalls, where TCP runs idle and looses the state of the network. According to RFC5681 section 4.1, the cwnd should be reset to the Restart Window. However, cwnd will be re-calculated by cubic as soon as=20= cwnd exceeds ssthresh. Without resetting the cubic epoch, the = calculation is based off the last time an actual congestion event happend - which = may be many tens of thousands of RTTs in the past. This results in excessive jumps of cwnd or integer overflows. The observable result are huge traffic burst and self-inflicted drops. Note: This patch ONLY addresses a very frequent problem case around after-idle. Other problematic scenarios revolve around clients signaling a small=20 receive window, where the session is for a long period limited by that. Once the client decides to suddenly signal a larger receive window, the t_cong_last can still be a very long time in the past, resulting in the same issues as observed before this patch with after-idle = sessions. >=20 > Submitted by: Richard Scheffenegger > Reviewed by: Cheng Cui > Differential Revision: https://reviews.freebsd.org/D18982 https://reviews.freebsd.org/D18954 >=20 > Modified: > head/sys/netinet/cc/cc_cubic.c >=20 > Modified: head/sys/netinet/cc/cc_cubic.c > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/sys/netinet/cc/cc_cubic.c Thu Nov 14 15:10:01 2019 = (r354707) > +++ head/sys/netinet/cc/cc_cubic.c Thu Nov 14 16:28:02 2019 = (r354708) > @@ -78,6 +78,7 @@ static int cubic_mod_init(void); > static void cubic_post_recovery(struct cc_var *ccv); > static void cubic_record_rtt(struct cc_var *ccv); > static void cubic_ssthresh_update(struct cc_var *ccv); > +static void cubic_after_idle(struct cc_var *ccv); >=20 > struct cubic { > /* Cubic K in fixed point form with CUBIC_SHIFT worth of = precision. */ > @@ -112,6 +113,7 @@ struct cc_algo cubic_cc_algo =3D { > .conn_init =3D cubic_conn_init, > .mod_init =3D cubic_mod_init, > .post_recovery =3D cubic_post_recovery, > + .after_idle =3D cubic_after_idle, > }; >=20 > static void > @@ -192,7 +194,24 @@ cubic_ack_received(struct cc_var *ccv, uint16_t = type) > } > } >=20 > +/* > + * This is a Cubic specific implementation of after_idle. > + * - Reset cwnd by calling New Reno implementation of after_idle. > + * - Reset t_last_cong. > + */ > static void > +cubic_after_idle(struct cc_var *ccv) > +{ > + struct cubic *cubic_data; > + > + cubic_data =3D ccv->cc_data; > + > + newreno_cc_algo.after_idle(ccv); > + cubic_data->t_last_cong =3D ticks; > +} > + > + > +static void > cubic_cb_destroy(struct cc_var *ccv) > { > free(ccv->cc_data, M_CUBIC); > @@ -287,9 +306,6 @@ cubic_conn_init(struct cc_var *ccv) > static int > cubic_mod_init(void) > { > - > - cubic_cc_algo.after_idle =3D newreno_cc_algo.after_idle; > - > return (0); > } >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E39CDB15-9ECD-4DD5-8706-130B4E55DF3E>