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:   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
Thread-Topic: [PATCH net-next v2] tcp: Ensure DCTCP reacts to losses
Thread-Index: AQHU6uFJ5qKL9TJ2LUy0DTa6bmxAT6YsSKWAgAAmjID//+KCMIAAKfSA
Date:   Thu, 4 Apr 2019 18:55:18 +0000
Message-ID: <75CDFF88-5632-4A44-A2BF-5725CDDE7DCA@fb.com>
References: <20190404121731.13917-1-olivier.tilmans@nokia-bell-labs.com>
 <20190404.105243.1039649838417325989.davem@davemloft.net>
 <532BB0D8-95C8-4A4D-A73D-3B563909780F@fb.com>
 <AM6PR07MB4821BB64AF86A1A650C95000E0500@AM6PR07MB4821.eurprd07.prod.outlook.com>
In-Reply-To: <AM6PR07MB4821BB64AF86A1A650C95000E0500@AM6PR07MB4821.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.14.0.181208
received-spf: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="utf-7"
Content-ID: <DB381A052CB9AD4B961E3B7013D81BBC@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e20858d4-45fe-48dc-0e03-08d6b92f14e2
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 18:55:18.3453
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2360
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-04_10:,,
 signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 4/4/19, 11:39 AM, +ACI-Tilmans, Olivier (Nokia - BE/Antwerp)+ACI- +ADw-o=
livier.tilmans+AEA-nokia-bell-labs.com+AD4- wrote:

    +AD4- DCTCP is meant to be used in environments where the switches/rout=
ers 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 measur=
ed the
    +AD4- effect of this changed when DCTCP is used in environments where a=
ll the
    +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 use=
d in
    +AD4- order to protect incorrect uses of DCTCP.
   =20
    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 ne=
w 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.
   =20
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 beha=
vior
    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.
   =20
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.
   =20
    Olivier
   =20