Bug 243590 - TCP ECN not adhering extremely strictly to RFC3168 can cause massive TCP perf issues
Summary: TCP ECN not adhering extremely strictly to RFC3168 can cause massive TCP perf...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.2-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-net mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-25 16:19 UTC by Richard Scheffenegger
Modified: 2020-01-26 02:08 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Scheffenegger 2020-01-25 16:19:02 UTC
The TCP/IP ECN signaling loop looks like this

         -CE->   (latches ECE)
         <----  ACK, ECE
ACK, CWR ---->   (unlatches ECE)

However, RFC3168 has a SHOULD for sending the CWR with a *new* data packet.

New data packets usually are also marked as ECN-capable transport (ECT), while
control packets, pure ACKs and retransmissions are sent without IP ECT codepoint.

Some overly restrictive clients (Linux) explicitly only accept and process
CWR, if they are received on (new) data segments, but ignore them completely when set in other packets. While such an overly restrictive behavior is also problematic, BSD *should* adhere to the guidance of RFC3168 and sent out
CWR flags only when (new) data packets are sent out (sec 6.1.2) rather than simply the very next segment (sec. 6.1):

RFC3168, section 6.1:
  
      * The sender sets the CWR flag in the TCP header of the next
        packet sent to the receiver to acknowledge its receipt of and
        reaction to the ECN-Echo flag.

RFC3168, section 6.1.2:

   When an ECN-Capable TCP sender reduces its congestion window for any
   reason (because of a retransmit timeout, a Fast Retransmit, or in
   response to an ECN Notification), the TCP sender sets the CWR flag in
   the TCP header of the first new data packet sent after the window
   reduction. 


The interaction can lead to a race to the bottom, where cwnd is continually
decreased and kept at a very small value. This results in extremely poor
performance for ECN-enabled TCP sessions.