Date: Thu, 05 Apr 2018 18:09:53 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 227303] tcp cwnd grows without bounds while app/rwnd limited, interacts badly with rwnd autosize Message-ID: <bug-227303-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227303 Bug ID: 227303 Summary: tcp cwnd grows without bounds while app/rwnd limited, interacts badly with rwnd autosize Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: srichard@netapp.com Created attachment 192252 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D192252&action= =3Dedit sender rwnd constrained, client opend rwnd twice leading to excessive traff= ic burst While verifying the reason for huge SACK scoreboard overflow counters, I fo= und that the tcp stack will burst massive amounts of data when a client (with enabled receive window autosize) increases its receive window. Suffice it to say, that bursting ~300kB with 10G towards a 100Mbps client in 0.5ms twice is a recipie for carnage. While investigating, I found that this appears to be a zero-day issue. Since "forever", cwnd would be increased by max(smss*smss/cwnd,1) as long a= s in congestion avoidance phase - that is, as long as no loss happend. However, this behavior is clearly not intended by the design of TCP, even though no RFC clearly spells it out (with the exception of RFC2861, section= 2, paragraph 6 perhaps, but that is not the normative text therein). When cwnd can not be verified, that is, the sender being limited by either = rwnd (easy to detect) or the application (see RFC7661), cwnd *must not* grow wit= hout bounds. This probably passed undetected for so long, as receive windows traditional= ly were static (or at least didn't jump up by magnitudes, when TCP flow contro= l is actively used). However, many clients now feature receive window autoscale, starting off at rather small rwnd, and probing if increasing rwnd has a positive effect on goodput later in the connection - often when the sender was rwnd bound for a significant number of RTTs already (and cwnd grew unchecked in the backgrou= nd). This bug request is not about RFC7661, but only to clamp the growth of cwnd= to no more than rwnd (or perhaps rwnd+2*smss, like what linux did in the past). This should prevent the observed traffic bursts when receive window autosca= le on a client decides to suddenly increase the receive window after a phase w= hen the sender was rwnd constrained. See attached tcptrace graphs, with two line-rate bursts of traffic (the fir= st one is arguably not preventable, except for its magnitude, the 2nd one lead= s to significant burst loss and impacts other traffic (not shown). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-227303-8>