Claudio Jeker <cje...@diehard.n-r-g.com> wrote: > On Mon, Feb 08, 2021 at 07:46:46PM +0100, Alexander Bluhm wrote: > > On Mon, Feb 08, 2021 at 07:03:59PM +0100, Jan Klemkow wrote: > > > On Mon, Feb 08, 2021 at 03:42:54PM +0100, Alexander Bluhm wrote: > > > > On Wed, Feb 03, 2021 at 11:20:04AM +0100, Claudio Jeker wrote: > > > > > Just commit it. OK claudio@ > > > > > If people see problems we can back it out again. > > > > > > > > This has huge impact on TCP performance. > > > > > > > > http://bluhm.genua.de/perform/results/2021-02-07T00%3A01%3A40Z/perform.html > > > > > > > > For a single TCP connection between to OpenBSD boxes, througput > > > > drops by 77% from 3.1 GBit/sec to 710 MBit/sec. But with 100 > > > > parallel connections the througput over all increases by 5%. > > > > > > For single connections our kernel is limited to send out 4 max TCP > > > segments. I don't see that, because I just measured with 10 and 30 > > > streams in parallel. > > > > > > FreeBSD disabled it 20 yeas ago. > > > https://github.com/freebsd/freebsd-src/commit/d912c694ee00de5ea0f46743295a0fc603cab562 > > > > TCP_MAXBURST was added together with SACK in rev 1.12 of tcp_output.c > > to our code base. > > > > ---------------------------- > > revision 1.12 > > date: 1998/11/17 19:23:02; author: provos; state: Exp; lines: +239 -14; > > NewReno, SACK and FACK support for TCP, adapted from code for BSDI > > by Hari Balakrishnan (h...@lcs.mit.edu), Tom Henderson > > (t...@cs.berkeley.edu) > > and Venkat Padmanabhan (padma...@cs.berkeley.edu) as part of the > > Daedalus research group at the University of California, > > (http://daedalus.cs.berkeley.edu). [I was able to do this on time spent > > at the Center for Information Technology Integration (citi.umich.edu)] > > ---------------------------- > > > > > I would suggest to remove the whole feature. > > > > Sending 4 segments per call to tcp_output() cannot scale. Bandwith > > increases, window size grows, but segment size is 1500 for decades. > > > > With this diff on top of jan's delay ACK behavior I get 4.1 GBit/sec > > over a single TCP connection using tcpbench -S1000000. Before both > > changes it was only 3.0. > > > > I recommend removing TCP_MAXBURST like FreeBSD did. > > > > I agree that this maxburst limit is no longer adequate. TCP New Reno > RFC6582 has the following: > > In Section 3.2, step 3 above, it is noted that implementations should > take measures to avoid a possible burst of data when leaving fast > recovery, in case the amount of new data that the sender is eligible > to send due to the new value of the congestion window is large. This > can arise during NewReno when ACKs are lost or treated as pure window > updates, thereby causing the sender to underestimate the number of > new segments that can be sent during the recovery procedure. > Specifically, bursts can occur when the FlightSize is much less than > the new congestion window when exiting from fast recovery. One > simple mechanism to avoid a burst of data when leaving fast recovery > is to limit the number of data packets that can be sent in response > to a single acknowledgment. (This is known as "maxburst_" in ns-2 > [NS].) Other possible mechanisms for avoiding bursts include rate- > based pacing, or setting the slow start threshold to the resultant > congestion window and then resetting the congestion window to > FlightSize. A recommendation on the general mechanism to avoid > excessively bursty sending patterns is outside the scope of this > document. > > While I agree that bursts need to be limited I think the implementation of > TCP_MAXBURST is bad. Since FreeBSD removed the code I guess nobody really > ran into issues of additional packet loss because of the burts. So go > ahead and remove it. OK claudio@
that makes sense. ok deraadt
