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:     David Miller <davem@davemloft.net>,
        "olivier.tilmans@nokia-bell-labs.com" 
        <olivier.tilmans@nokia-bell-labs.com>
CC:     "koen.de_schepper@nokia-bell-labs.com" 
        <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: AQHU6uFJ5qKL9TJ2LUy0DTa6bmxAT6YsSKWAgAAmjIA=
Date:   Thu, 4 Apr 2019 18:10:42 +0000
Message-ID: <532BB0D8-95C8-4A4D-A73D-3B563909780F@fb.com>
References: <20190404121731.13917-1-olivier.tilmans@nokia-bell-labs.com>
 <20190404.105243.1039649838417325989.davem@davemloft.net>
In-Reply-To: <20190404.105243.1039649838417325989.davem@davemloft.net>
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: <D383DEF0D7FEE143BC182D62AE97CDE5@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: db3e0302-022b-4469-110d-08d6b928d9cd
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 18:10:42.1588
 (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: BYAPR15MB2822
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-04_09:,,
 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


+/v8-On 4/4/19, 10:53 AM, +ACI-David Miller+ACI- +ADw-davem+AEA-davemloft.n=
et+AD4- wrote:

    From: +ACI-Tilmans, Olivier (Nokia - BE/Antwerp)+ACI- +ADw-olivier.tilm=
ans+AEA-nokia-bell-labs.com+AD4-
    Date: Thu, 4 Apr 2019 12:24:02 +-0000
   =20
    +AD4- RFC8257 +AKc-3.5 explicitly states that +ACI-A DCTCP sender MUST =
react to
    +AD4- loss episodes in the same way as conventional TCP+ACI-.
    ...
    +AD4- This patch replace the clamping of alpha by setting ssthresh to
    +AD4- half of cwnd for both fast retransmissions and RTOs, at most once
    +AD4- per RTT. Consequently, the dctcp+AF8-clamp+AF8-alpha+AF8-on+AF8-l=
oss module parameter
    +AD4- has been removed.
   =20
    Applied to 'net' and queued up for -stable, thanks.
   =20
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 envir=
onments where it was not meant to be used. Has anyone measured the effect o=
f this changed when DCTCP is used in environments where all the switches/ro=
uters do ECN marking? My concern is that we could end up hurting performanc=
e when DCTCP is used how it was meant to be used in order to protect incorr=
ect uses of DCTCP.