From owner-freebsd-bugs@freebsd.org Thu Apr 5 18:10:04 2018 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38D70F97817 for ; Thu, 5 Apr 2018 18:10:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BFE856908A for ; Thu, 5 Apr 2018 18:10:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id D3AFC159FB for ; Thu, 5 Apr 2018 18:10:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w35IA2aa046471 for ; Thu, 5 Apr 2018 18:10:02 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w35IA2XZ046461 for freebsd-bugs@FreeBSD.org; Thu, 5 Apr 2018 18:10:02 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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 Date: Thu, 05 Apr 2018 18:09:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: srichard@netapp.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 18:10:04 -0000 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.=