From owner-freebsd-bugs@freebsd.org Sat Jan 25 16:19:03 2020 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 289141F3432 for ; Sat, 25 Jan 2020 16:19:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 484h5y6zhZz4g91 for ; Sat, 25 Jan 2020 16:19:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id EDAA11F3431; Sat, 25 Jan 2020 16:19:02 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ED59E1F342F for ; Sat, 25 Jan 2020 16:19:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 484h5y4qy8z4g90 for ; Sat, 25 Jan 2020 16:19:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 8464DADAB for ; Sat, 25 Jan 2020 16:19:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 00PGJ2Wa017444 for ; Sat, 25 Jan 2020 16:19:02 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 00PGJ2JO017443 for bugs@FreeBSD.org; Sat, 25 Jan 2020 16:19: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: bugs@FreeBSD.org Subject: [Bug 243590] TCP ECN not adhering extremely strictly to RFC3168 can cause massive TCP perf issues Date: Sat, 25 Jan 2020 16:19:02 +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: 11.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rscheff@gmx.at X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: 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 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.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2020 16:19:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D243590 Bug ID: 243590 Summary: TCP ECN not adhering extremely strictly to RFC3168 can cause massive TCP perf issues Product: Base System Version: 11.2-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: rscheff@gmx.at 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), wh= ile 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.=20 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. --=20 You are receiving this mail because: You are the assignee for the bug.=