Re: [Rdma-cc-interest] Congestion Control for Large Scale Data Center Networks

"Black, David" <David.Black@dell.com> Tue, 24 September 2019 13:50 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: rdma-cc-interest@ietfa.amsl.com
Delivered-To: rdma-cc-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04BE1200C7 for <rdma-cc-interest@ietfa.amsl.com>; Tue, 24 Sep 2019 06:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=CIqDNuk7; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=DCZzDFdN
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVoE0e6B1Ge1 for <rdma-cc-interest@ietfa.amsl.com>; Tue, 24 Sep 2019 06:50:55 -0700 (PDT)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5DB3120026 for <rdma-cc-interest@ietf.org>; Tue, 24 Sep 2019 06:50:51 -0700 (PDT)
Received: from pps.filterd (m0170397.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8ODZcdb011973 for <rdma-cc-interest@ietf.org>; Tue, 24 Sep 2019 09:50:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=JBzHFIit7lg7l8tEKAn9sTaWiAo3XLQpbq7nynWmdcA=; b=CIqDNuk7uD8JN3a37p3Zwk6IRoF6521npBQgWX/yT82gg6RtC6BSn2prF7IMyvemW6/z vByamkXMsTbtCCzPXBdMqsD8f6Bhu4g6meGBO4R0o7QC8c6415DIxMt2K6axSzVbuWuu 7uWjC607seTS3PGlefhdHz8DUct7bWrzIOb7v1pD2RjEsPACFMBwRxdvB7eUKDk7FQom FQ4uBTV72jEprlI1iFnpj130SRhC0ok5tHJmS4SqLuScUJY2qo0M9t0gtYwpdCFQFumS PBni62gIW8is5vm3EKyQS+3K0IxBcTlJvniV+3TCXC0eikvi607Y1yOKKkZmlnAryDAq 8g==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2v5fe2wuxx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <rdma-cc-interest@ietf.org>; Tue, 24 Sep 2019 09:50:50 -0400
Received: from pps.filterd (m0144102.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8ODc518001148 for <rdma-cc-interest@ietf.org>; Tue, 24 Sep 2019 09:50:50 -0400
Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-00154901.pphosted.com with ESMTP id 2v7dy86mk5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <rdma-cc-interest@ietf.org>; Tue, 24 Sep 2019 09:50:50 -0400
Received: from m0144102.ppops.net (m0144102.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id x8ODmLNl026837 for <rdma-cc-interest@ietf.org>; Tue, 24 Sep 2019 09:50:49 -0400
Received: from mailuogwdur.emc.com (mailuogwdur-nat.lss.emc.com [128.221.224.79] (may be forged)) by mx0b-00154901.pphosted.com with ESMTP id 2v7dy86mjw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 24 Sep 2019 09:50:49 -0400
Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8ODoVX7006372 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Sep 2019 09:50:49 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com x8ODoVX7006372
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1569333049; bh=WQVa5O5R2+xSTdXVKiOFqofAbpY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=DCZzDFdNR4QTu5pqMvwZVDu8ZnAEuTvN5ySROhCcJm9DzBOAAhvLYRLcwEbMebWfK 0LgXgzFaHRK8EzhuELygWwHgSTkMpH3z0DSK3junMwKFeNZOMCGf41BzggLe7PkACb kJQ8O4cRJfD1kGmUKcAs0+8+aVhmxMh+NOejFCAI=
Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd53.lss.emc.com (RSA Interceptor); Tue, 24 Sep 2019 09:49:45 -0400
Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8ODnjNb009643 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Tue, 24 Sep 2019 09:49:45 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0439.000; Tue, 24 Sep 2019 09:49:44 -0400
From: "Black, David" <David.Black@dell.com>
To: "Roni Even (A)" <roni.even@huawei.com>, "rdma-cc-interest@ietf.org" <rdma-cc-interest@ietf.org>
Thread-Topic: Congestion Control for Large Scale Data Center Networks
Thread-Index: AdVypdasUsSCz31jTEKThKlG/zI4pAANoukw
Date: Tue, 24 Sep 2019 13:49:43 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949363070F8D1@MX307CL04.corp.emc.com>
References: <6E58094ECC8D8344914996DAD28F1CCD23D6B64E@DGGEMM506-MBX.china.huawei.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD23D6B64E@DGGEMM506-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-09-24T13:32:23.6257562Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [10.105.8.135]
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363070F8D1MX307CL04corpem_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-24_06:2019-09-23,2019-09-24 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 malwarescore=0 clxscore=1011 priorityscore=1501 phishscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 impostorscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909240136
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 adultscore=0 bulkscore=0 priorityscore=1501 impostorscore=0 clxscore=1011 lowpriorityscore=0 mlxlogscore=999 malwarescore=0 mlxscore=0 suspectscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909240136
Archived-At: <https://mailarchive.ietf.org/arch/msg/rdma-cc-interest/lCB1zU-PPcNCkXHbCCv6c9E826U>
Subject: Re: [Rdma-cc-interest] Congestion Control for Large Scale Data Center Networks
X-BeenThere: rdma-cc-interest@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Congestion Control for Large Scale HPC/RDMA Data Centers <rdma-cc-interest.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rdma-cc-interest>, <mailto:rdma-cc-interest-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rdma-cc-interest/>
List-Post: <mailto:rdma-cc-interest@ietf.org>
List-Help: <mailto:rdma-cc-interest-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rdma-cc-interest>, <mailto:rdma-cc-interest-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Sep 2019 13:50:58 -0000

Hi Roni,

> it will be good if the IETF will be able to recommend an e2e congestion protocol that will allow interoperability between vendors and that will leverage the information from the network .

... and I'd like $10 million in small unmarked bills, please :-).

Seriously, IMHO, the goal for the network ought to be robustness to the variety of current congestion control protocols, not all of which coexist well in the same switch queue.   In other words, I think the better goal to pursue is "to provide fairness between different applications that may use different congestion algorithms" although I would suggest avoiding the word "fairness" in this context as it's typically used to mean "TCP fairness" in this context, whereas something more general is wanted.   In contrast, pursuit of a single e2e congestion protocol that will be universally adopted appears unreasonable and unachievable at this juncture.

There is important work going on in the TSVWG WG that will improve that congestion control protocol coexistence and help achieve low latency (which is not possible in all cases for traffic mix reasons that I won't explain here for brevity).

I suggest reviewing the TSVWG drafts on L4S and SCE, as well as the presentation materials from the Montreal TSVWG meetings.  Here are some pointers:

  *   L4S drafts (@ https://datatracker.ietf.org/wg/tsvwg/documents/): draft-ietf-tsvwg-{l4s-arch,aqm-dualq-coupled,ecn-l4s-id}
  *   SCE drafts: Start with draft-morton-tsvwg-sce - the other two draft-morton-* drafts are somewhat related, but the sce draft is the core draft.
  *   TSVWG presentation material from Montreal: https://datatracker.ietf.org/meeting/105/session/tsvwg
We (TSVWG WG) would greatly appreciate some more data center and RDMA "eyes" on this material, as it is highly relevant to data centers.

Thanks, --David (TSVWG WG co-chair)

From: Rdma-cc-interest <rdma-cc-interest-bounces@ietf.org> On Behalf Of Roni Even (A)
Sent: Tuesday, September 24, 2019 3:08 AM
To: rdma-cc-interest@ietf.org
Subject: [Rdma-cc-interest] Congestion Control for Large Scale Data Center Networks


[EXTERNAL EMAIL]

Hi,
We had side meetings at the last two IETF meeting about better congestion control for data centers with good number of participants.

The high throughput of the Data center networks require a good congestion control for data centers should provide low latency, fast convergence and high link utilization.  Since multiple  applications with different requirements may run on the DC network it  is important to provide fairness between different applications that may use different congestion algorithms.  An important issue from the  user perspective is to achieve short Flow Completion Time (FCT).

It is clear that we are not going to make changes to ROCE but we still would like to look at good e2e congestion control. Currently there are multiple published work presented in different papers (examples are DCQCN, HPCC, RPC) but it will be good if the IETF will be able to recommend an e2e congestion protocol that will allow interoperability between vendors and that will leverage the information from the network .

We would like to have a side meeting in Singapore and intend to submit a draft that will discussed the different options hoping to be able to collaborate between the interested people to work on a common direction.

Regards
Roni Even