Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "Tilmans, Olivier (Nokia - BE/Antwerp)" 
        <olivier.tilmans@nokia-bell-labs.com>
To:     Lawrence Brakmo <brakmo@fb.com>, David Miller <davem@davemloft.net>
CC:     "De Schepper, Koen (Nokia - BE/Antwerp)" 
        <koen.de_schepper@nokia-bell-labs.com>,
        "research@bobbriscoe.net" <research@bobbriscoe.net>,
        "fw@strlen.de" <fw@strlen.de>,
        "borkmann@iogearbox.net" <borkmann@iogearbox.net>,
        "ycheng@google.com" <ycheng@google.com>,
        "ncardwell@google.com" <ncardwell@google.com>,
        "edumazet@google.com" <edumazet@google.com>,
        "agshew@gmail.com" <agshew@gmail.com>,
        "glenn.judd@morganstanley.com" <glenn.judd@morganstanley.com>,
        "kuznet@ms2.inr.ac.ru" <kuznet@ms2.inr.ac.ru>,
        "yoshfuji@linux-ipv6.org" <yoshfuji@linux-ipv6.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH net-next v2] tcp: Ensure DCTCP reacts to losses
Thread-Topic: [PATCH net-next v2] tcp: Ensure DCTCP reacts to losses
Thread-Index: AQHU6uFJ5qKL9TJ2LUy0DTa6bmxAT6YsSKWAgAAmjID//+KCMA==
Date:   Thu, 4 Apr 2019 18:39:31 +0000
Message-ID: <AM6PR07MB4821BB64AF86A1A650C95000E0500@AM6PR07MB4821.eurprd07.prod.outlook.com>
References: <20190404121731.13917-1-olivier.tilmans@nokia-bell-labs.com>
 <20190404.105243.1039649838417325989.davem@davemloft.net>
 <532BB0D8-95C8-4A4D-A73D-3B563909780F@fb.com>
In-Reply-To: <532BB0D8-95C8-4A4D-A73D-3B563909780F@fb.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nokia-bell-labs.com does not
 designate permitted sender hosts)
Content-Type: text/plain; charset="utf-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f0244d55-b33e-43ca-5b32-08d6b92ce08f
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 18:39:31.6174
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB6072
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

+AD4- DCTCP is meant to be used in environments where the switches/routers =
do
+AD4- ECN marking, so it is not surprising that it performs badly when used=
 in
+AD4- environments where it was not meant to be used. Has anyone measured t=
he
+AD4- effect of this changed when DCTCP is used in environments where all t=
he
+AD4- switches/routers do ECN marking? My concern is that we could end up
+AD4- hurting performance when DCTCP is used how it was meant to be used in
+AD4- order to protect incorrect uses of DCTCP.

The results reported are indeed from a non-optimal setting, and mostly to
show that it was ignoring losses. In practice, we only use DCTCP on=20
ECN-enabled AQMs, and rarely see the loss reaction (e.g., a burst of new fl=
ows
IW that congest the ToR switch, in which case I'd argue the behavior is
beneficial). I cannot estimate the impact on FB's workloads though.

I had originally put a module parameter to make this loss reaction behavior
optional, mostly to enable people to check first whether it was safe to use=
=20
with their configuration. In hindsight, I should have waited a bit more
before submitting the v2 with its removal as requested.


Olivier