RFC8312 Cubic
Hi, we encounted an issue with the BSD11 cubic implementation during testing, when dealing with app-stalled and app-limited traffic patterns. The gist is, that at least in the after_idle cong_func for cubic, the states for ssthresh and cubic epoch time are not reset, leading to excessive cwnd values (overflows even) and self-inflicted drops due to dramatic burst transmissions. Bug Report, or Patch directly to Phabricator (when it is fully qualified)? Best regards, Richard ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: RFC8312 Cubic
On Wed, Jan 23, 2019 at 12:34 PM Scheffenegger, Richard < richard.scheffeneg...@netapp.com> wrote: > Hi, > > we encounted an issue with the BSD11 cubic implementation during testing, > when dealing with app-stalled and app-limited traffic patterns. > > The gist is, that at least in the after_idle cong_func for cubic, the > states for ssthresh and cubic epoch time are not reset, leading to > excessive cwnd values (overflows even) and self-inflicted drops due to > dramatic burst transmissions. > > Bug Report, or Patch directly to Phabricator (when it is fully qualified)? > Search the freebsd-stable mailing list archives for the thread with subject line: HEADS UP: TCP CUBIC Broken on 12.0-RELEASE/STABLE https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090255.html An Errata Notice should be going out sometime this month-ish. -- Freddie Cash fjwc...@gmail.com ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: RFC8312 Cubic
> On 23. Jan 2019, at 21:41, Freddie Cash wrote: > > On Wed, Jan 23, 2019 at 12:34 PM Scheffenegger, Richard < > richard.scheffeneg...@netapp.com> wrote: > >> Hi, >> >> we encounted an issue with the BSD11 cubic implementation during testing, >> when dealing with app-stalled and app-limited traffic patterns. >> >> The gist is, that at least in the after_idle cong_func for cubic, the >> states for ssthresh and cubic epoch time are not reset, leading to >> excessive cwnd values (overflows even) and self-inflicted drops due to >> dramatic burst transmissions. >> >> Bug Report, or Patch directly to Phabricator (when it is fully qualified)? >> > > Search the freebsd-stable mailing list archives for the thread with subject > line: > > HEADS UP: TCP CUBIC Broken on 12.0-RELEASE/STABLE > > https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090255.html > > An Errata Notice should be going out sometime this month-ish. Aren't you referring to: https://www.freebsd.org/security/advisories/FreeBSD-EN-19:01.cc_cubic.asc Best regards Michael > > -- > Freddie Cash > fjwc...@gmail.com > ___ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
RE: RFC8312 Cubic
Thanks, But this is against BSD11 (and checked against HEAD, which is virtually the same) – sorry for omitting this critical piece of info. The issue we are observing is a performance degradation (only) when the sender has frequent idle periods from the application (not) handing new data continuously to the socket. That is, new data is generated at infrequent intervals, ranging from sub-RTT to dozens of RTTs, with varying size (sub window, to multiple windows worth). The problem sufaces only sometimes, after the RTO timer has run out (cc_after_idle is called in tcp_output). Depending on the exact timing, cwnd can then become very large (>int32), with the burst harming the session itself, or very small (2 MSS) growing very slowly at first… But it’s “just” a ~25% reduced performance for that application compared with vanilla newreno. In general (more streaming applications, longer RTT paths) cubic beats newreno by a large margin in goodput (up to 5x higher for transcontinental). We suspect that not clearing the cubic state in after_idle may be part of the culprit here (cubic epoch should not stretch beyond idle periods, according to RFC8312), and slow start not always invoked with a properly (reset) ssthresh. Best regards, Richard From: Freddie Cash Sent: Mittwoch, 23. Jänner 2019 21:41 To: Scheffenegger, Richard Cc: freebsd-transp...@freebsd.org; freebsd-net@freebsd.org Subject: Re: RFC8312 Cubic NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Wed, Jan 23, 2019 at 12:34 PM Scheffenegger, Richard mailto:richard.scheffeneg...@netapp.com>> wrote: Hi, we encounted an issue with the BSD11 cubic implementation during testing, when dealing with app-stalled and app-limited traffic patterns. The gist is, that at least in the after_idle cong_func for cubic, the states for ssthresh and cubic epoch time are not reset, leading to excessive cwnd values (overflows even) and self-inflicted drops due to dramatic burst transmissions. Bug Report, or Patch directly to Phabricator (when it is fully qualified)? Search the freebsd-stable mailing list archives for the thread with subject line: HEADS UP: TCP CUBIC Broken on 12.0-RELEASE/STABLE https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090255.html An Errata Notice should be going out sometime this month-ish. -- Freddie Cash fjwc...@gmail.com<mailto:fjwc...@gmail.com> ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
