From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0D4183B2A4 for ; Tue, 28 Jan 2020 17:56:05 -0500 (EST) Received: by mail-io1-xd30.google.com with SMTP id c16so16407483ioh.6 for ; Tue, 28 Jan 2020 14:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=xRzjL8twNUtpwHlWPG8VjSw70/2CzKW+yARst7f8Cvg=; b=dcwA4O+Z/DLnUA16WUcU/NHV7I3Jozj37SUcGDJ1XSr/PtOYS52nvXnzjW620GpC6/ 4x0DgoU4ohVL5vTH6zo4BamIJnuaD/oesZGRAmzdO4KwlF9AWeAkfkgamCakRJ861/d8 W8+1ilStVHfALSd8my7c8rPAWE3U+CNijm2q6A5PLgfsZgHYKeSVog0uxBjTPmOJpgF3 uoFI4vrSOkRbm5G0bRN5V1REWV1B74EWaWfvKrzB7n9VwMulnfVd6XiCclKgNhaMS4tx qEf8lUAlNtbURqHjw0a2PQrmFzKK502QPL9njOC7REWbac1nhWCuOt4zTUiMqQJMLOEK ZE3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=xRzjL8twNUtpwHlWPG8VjSw70/2CzKW+yARst7f8Cvg=; b=TAWc5jPfe2oDriZD1vSX6xmP5nn94HZSfvMaTbOu7Ax1Ue3rsgLobux9x9nezxYFEe k5OImdO53aAfevu8YNtRQS2l9So9qo3LHSlzL4OKUr3zReXPkBIqmJ/VzEIiNDbV6uic 7JG4HJA3MzXfGiToW/Q7LsROwoedJz57OV57bCugLdSG7/n88KA8ia1HO5iX1AMGJHi1 4t5AHDiRvaizlowgQ8xPHcj9elwUcHHCpmWIm7dsgy0wJMLWh6ti8b2ZnyRkIP0Z8S8C D+C4GOKwcwotwyRyHnbvsmTFOS1B1KN1+pmPb3FTtNr2QZ/Qv2Q+L3moOL1+Z5VEJDCX lx2Q== X-Gm-Message-State: APjAAAVmSBbs4g3AhYXoA3d3v63/AtEZmQvlwytCdPZftqylHiLBHxJv hTzk/JP4zF9sR1OUcJhVPJGFmrPaJFjbHFS3UKeFattb X-Google-Smtp-Source: APXvYqxAlscd2QyxWYEJi6jEwmTcUMtl+PGyLMI2/bSIRJaNGQ6RJDuVl+Bu6//nR5EDnDlHlhxGbGfjQ/nFotgXNqg= X-Received: by 2002:a02:c773:: with SMTP id k19mr19249213jao.61.1580252164257; Tue, 28 Jan 2020 14:56:04 -0800 (PST) MIME-Version: 1.0 References: <20200127054830.53973d51@hermes.lan> In-Reply-To: <20200127054830.53973d51@hermes.lan> From: Dave Taht Date: Tue, 28 Jan 2020 14:55:52 -0800 Message-ID: To: ECN-Sane Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Ecn-sane] Fwd: Fw: [Bug 206319] New: ECN header flag processing overly restrictive in TCP X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 22:56:05 -0000 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 Date: Mon, Jan 27, 2020 at 5:48 AM Subject: Fw: [Bug 206319] New: ECN header flag processing overly restrictive in TCP To: 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=3D206319 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 arr= ives together with some data (but apparently does accept it on retransmissions). This has been found to be an interoperability issue with *BSD, where the CW= R 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=3D243231 Nevertheless, CWR processing as receiver should be less restrictive, to mee= t 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 additiona= l ECE flags as another round of congestion. To which the data sender reacts b= y continous reductions of the congestion window until extremely low packet transmission rates (1 packet per delayed ACK timeout, or even persist timeo= ut (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 t= rack the issue in the field (impacted environments). -- You are receiving this mail because: You are the assignee for the bug. --=20 Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729