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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 4 Apr 2019 18:55:18 +0000
From:   Lawrence Brakmo <brakmo@...com>
To:     "Tilmans, Olivier (Nokia - BE/Antwerp)" 
        <olivier.tilmans@...ia-bell-labs.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


On 4/4/19, 11:39 AM, "Tilmans, Olivier (Nokia - BE/Antwerp)" <olivier.tilmans@...ia-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
    

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ