Re: [PATCH net-next v2] tcp: Ensure DCTCP reacts to losses

From: Lawrence Brakmo <brakmo@fb.com>
To: "Tilmans,
	Olivier (Nokia - BE/Antwerp)" 
	<olivier.tilmans@nokia-bell-labs.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
Date: Thu, 4 Apr 2019 18:55:18 +0000	[thread overview]
Message-ID: <75CDFF88-5632-4A44-A2BF-5725CDDE7DCA@fb.com> (raw)
In-Reply-To: <AM6PR07MB4821BB64AF86A1A650C95000E0500@AM6PR07MB4821.eurprd07.prod.outlook.com>

On 4/4/19, 11:39 AM, "Tilmans, Olivier (Nokia - BE/Antwerp)" <olivier.tilmans@nokia-bell-labs.com> wrote:

    > DCTCP is meant to be used in environments where the switches/routers do
    > ECN marking, so it is not surprising that it performs badly when used in
    > environments where it was not meant to be used. Has anyone measured the
    > effect of this changed when DCTCP is used in environments where all the
    > switches/routers do ECN marking? My concern is that we could end up
    > hurting performance when DCTCP is used how it was meant to be used in
    > 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 
    ECN-enabled AQMs, and rarely see the loss reaction (e.g., a burst of new flows
    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.

In some of our environments we do see packet losses at high workloads with DCTCP.
My concern is that I have no idea whether this change will be beneficial or
harmful in those environments.

    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 
    with their configuration. In hindsight, I should have waited a bit more
    before submitting the v2 with its removal as requested.

The module parameter, even if enabled by default, would have been
preferable since it would support environments where this feature
turned out to be sub-optimal.

    Olivier