[Ecn-sane] Fwd: Fw: [Bug 206319] New: ECN header flag processing overly restrictive in TCP

[Dave Taht <dave.taht@gmail.com>]

My understanding from reading rfc3168 is that the retransmit should be
unprotected and yes! sometimes force a RTO should the link be so
overburdened as to need to drop packets or back off hard. The idea
that marking retransmits with ECT(0) might save on retransmits is
irrelevant, although I wish modern tcps would somehow drop down to a
cwnd of 1 under extreme congestion.

https://reviews.freebsd.org/D23118

---------- Forwarded message ---------
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Mon, Jan 27, 2020 at 5:48 AM
Subject: Fw: [Bug 206319] New: ECN header flag processing overly
restrictive in TCP
To: <netdev@vger.kernel.org>




Begin forwarded message:

Date: Mon, 27 Jan 2020 08:15:36 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 206319] New: ECN header flag processing overly restrictive in TCP


https://bugzilla.kernel.org/show_bug.cgi?id=206319

            Bug ID: 206319
           Summary: ECN header flag processing overly restrictive in TCP
           Product: Networking
           Version: 2.5
    Kernel Version: HEAD
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Other
          Assignee: stephen@networkplumber.org
          Reporter: rscheff@gmx.at
        Regression: No

RFC3168 states, that a CWR flag "SHOULD" be *sent* together with a new data
segment.

However, linux is processing the CWR flag as data receiver ONLY when it arrives
together with some data (but apparently does accept it on retransmissions).

This has been found to be an interoperability issue with *BSD, where the CWR is
sent as quickly as possible, including on pure ACKs (or retransmissions) so
far. That deviation from RFC3168 there is reported at
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243231

Nevertheless, CWR processing as receiver should be less restrictive, to meet
the sprit of Postels Law: "Be liberal in what you accept, and conservative in
what you send."


This has been demonstrated to be a dramatic performance impediment, as the data
receiver (linux) keeps the ECE latched, while *BSD interprets the additional
ECE flags as another round of congestion. To which the data sender reacts by
continous reductions of the congestion window until extremely low packet
transmission rates (1 packet per delayed ACK timeout, or even persist timeout
(5s) are hit, and kept at that level for extensive periods of time.

Discussed this issue with Neal and Yuchung already, this bug report is to track
the issue in the field (impacted environments).

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


-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729