[Bug 227303] tcp cwnd grows without bounds while app/rwnd limited, interacts badly with rwnd autosize

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227303

            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 at FreeBSD.org
          Reporter: srichard at netapp.com

Created attachment 192252
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192252&action=edit
sender rwnd constrained, client opend rwnd twice leading to excessive traffic
burst

While verifying the reason for huge SACK scoreboard overflow counters, I found
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 as 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 without
bounds.

This probably passed undetected for so long, as receive windows traditionally
were static (or at least didn't jump up by magnitudes, when TCP flow control 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 background).

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 autoscale
on a client decides to suddenly increase the receive window after a phase when
the sender was rwnd constrained.

See attached tcptrace graphs, with two line-rate bursts of traffic (the first
one is arguably not preventable, except for its magnitude, the 2nd one leads to
significant burst loss and impacts other traffic (not shown).

-- 
You are receiving this mail because:
You are the assignee for the bug.