RFC8312 Cubic

[Scheffenegger, Richard]

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 <fjwcash at gmail.com>
Sent: Mittwoch, 23. Jänner 2019 21:41
To: Scheffenegger, Richard <Richard.Scheffenegger at netapp.com>
Cc: freebsd-transport at freebsd.org; freebsd-net at 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 <Richard.Scheffenegger at netapp.com<mailto:Richard.Scheffenegger at 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
fjwcash at gmail.com<mailto:fjwcash at gmail.com>