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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 4 Apr 2019 18:39:31 +0000
From:   "Tilmans, Olivier (Nokia - BE/Antwerp)" 
        <olivier.tilmans@...ia-bell-labs.com>
To:     Lawrence Brakmo <brakmo@...com>, David Miller <davem@...emloft.net>
CC:     "De Schepper, Koen (Nokia - BE/Antwerp)" 
        <koen.de_schepper@...ia-bell-labs.com>,
        "research@...briscoe.net" <research@...briscoe.net>,
        "fw@...len.de" <fw@...len.de>,
        "borkmann@...earbox.net" <borkmann@...earbox.net>,
        "ycheng@...gle.com" <ycheng@...gle.com>,
        "ncardwell@...gle.com" <ncardwell@...gle.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "agshew@...il.com" <agshew@...il.com>,
        "glenn.judd@...ganstanley.com" <glenn.judd@...ganstanley.com>,
        "kuznet@....inr.ac.ru" <kuznet@....inr.ac.ru>,
        "yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net-next v2] tcp: Ensure DCTCP reacts to losses

> 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.

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.


Olivier