Re: [iccrg] introducing draft-even-iccrg-dc-fast-congestion

"Holland, Jake" <jholland@akamai.com> Wed, 13 November 2019 09:57 UTC

Return-Path: <jholland@akamai.com>
X-Original-To: iccrg@ietfa.amsl.com
Delivered-To: iccrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC0012009E for <iccrg@ietfa.amsl.com>; Wed, 13 Nov 2019 01:57:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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=akamai.com
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 ku0HB_8vOQ1z for <iccrg@ietfa.amsl.com>; Wed, 13 Nov 2019 01:57:41 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 AB0E0120088 for <iccrg@irtf.org>; Wed, 13 Nov 2019 01:57:41 -0800 (PST)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xAD9uvtc010796; Wed, 13 Nov 2019 09:57:35 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=LG3556gnTLo3n0SMncSrwjgXRaYiSYsprKhMJTXWeJY=; b=LQ4TfzyexSbiJh5XEm882eC6nnnBczbCa01vVcYU6qUXcy9VLUDwhjp6RU7Lw2qQ/ews ACPeceSqdBek7oDIFsWd/2oDDHI8cTEnXtoLjhaqn9yYgqtFbGZLS2sdRyfstKIobsW4 yMTktzbhbWfc+Ys2XIiupoULRzQwTTByplro/erODdCZNnS9GUYMuzb2TJTvsnAOMITz 31j/sm8Osp3s6HV10qScPaxgAyUt2/JlAyJFbOMUD8JPRBNBIPZ6m58dLFmDtVg4UGEl oWJKnOLnawZ4Tu9GSihL7JqnXPUxsCbd1OfZQ49T9mf96FBcEcaoBpyrgS44tJVFYijS kw==
Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2w5p6pbyey-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Nov 2019 09:57:35 +0000
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAD9lNin028871; Wed, 13 Nov 2019 04:57:34 -0500
Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint8.akamai.com with ESMTP id 2w5snyt948-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 13 Nov 2019 04:57:34 -0500
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.165.122) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 13 Nov 2019 03:57:33 -0600
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.165.122]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.165.122]) with mapi id 15.00.1473.005; Wed, 13 Nov 2019 03:57:33 -0600
From: "Holland, Jake" <jholland@akamai.com>
To: Michael Welzl <michawe@ifi.uio.no>, iccrg IRTF list <iccrg@irtf.org>
Thread-Topic: [iccrg] introducing draft-even-iccrg-dc-fast-congestion
Thread-Index: AdWOIXQP9Tl8qH4zTESH2RWKfZGb7QE9qXQAAbf5aAA=
Date: Wed, 13 Nov 2019 09:57:32 +0000
Message-ID: <A4510362-F2A3-4562-9ADD-8E39666AD167@akamai.com>
References: <6E58094ECC8D8344914996DAD28F1CCD23D9DC0C@dggemm526-mbx.china.huawei.com> <24030CAE-F96B-4EB2-B36F-28534D413C05@ifi.uio.no>
In-Reply-To: <24030CAE-F96B-4EB2-B36F-28534D413C05@ifi.uio.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1e.0.191013
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.80.96]
Content-Type: text/plain; charset="utf-8"
Content-ID: <BEFC15BE39A11B4FB8B0C67F1640DFE3@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-13_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911130092
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-13_02:2019-11-13,2019-11-13 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 impostorscore=0 mlxscore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 malwarescore=0 phishscore=0 adultscore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911130093
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/lrym0qMLAPDoRKt611HxW9gP8Ik>
Subject: Re: [iccrg] introducing draft-even-iccrg-dc-fast-congestion
X-BeenThere: iccrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" <iccrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/iccrg>, <mailto:iccrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iccrg/>
List-Post: <mailto:iccrg@irtf.org>
List-Help: <mailto:iccrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/iccrg>, <mailto:iccrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Nov 2019 09:57:44 -0000

+1, I agree with most of what Michael said.  What the doc is suggesting
sounds like a useful direction to me.

I'm not sure the doc itself is useful to publish as an RFC, I'd be more
interested in a proposal that tries to do what the doc describes.  But
I do think the ideas put forth are interesting and would encourage
efforts to make them reality.

Intuitively, I'd think that with direct communication with network
nodes in a controlled environment, it should be possible to get better
performance more robustly than what you can do with inferring status
a bit at a time from reflecting CE/SCE marks in acks, and it would be
very cool to see an attempt to make that work well.

Best,
Jake

´╗┐On 2019-11-03, 23:59, "Michael Welzl" <michawe@ifi.uio.no>; wrote:

Hi,


> On 29 Oct 2019, at 07:34, Roni Even (A) <roni.even@huawei.com>; wrote:
> 
> Hi,
> We submitted the draft after discussing the topic of better congestion control for Data Centers in the last IETF meeting.
> The objective was to look at current congestion control mechanisms and propose a possible direction for DC CC.
>  
> The direction that looks promising to us is to reflect the network status more accurately taking into account that we are talking about a single DC domain.
>  
> We are looking for feedback if this direction looks promising and if there is an interest in working on this direction.

In my opinion, regarding "does this direction look promising": absolutely yes!   Internet congestion controls work with a secondary and very limited signal (implicit feedback, as the result of queuing behavior); if you have the luxury of using an earlier signal (as in mechanisms like HPCC), that should be strictly superior. E.g. DCTCP is a lot better than normal TCP, but still, the increase behavior is the same, as it's just clueless until the queue grows at least a little bit.


> The draft have some open questions that need to be addressed.

Some of them are very much case-by-case. E.g.: "Hardware implications" depend on the hardware  :)   And: "How to authenticate the validity of the data." - why do you need to, in your own datacenter?

These two issues are from a section that deals with giving feedback to the sender faster, e.g. by piggybacking on reverse traffic. My suggestion would be to consider this a second step, and deal with first things first - the questions in the section on "Reflect the network status more accurately". There, it very much depends on the mechanism that you want to use. E.g., the answer to: "How to add the metadata to the forward stream" may depend on the mechanism, as the amount of data to convey may differ quite a bit from one case to another. Your related text in section 4.4 seems to be quite focused on HPCC - that's not the only possible explicit feedback based mechanism. E.g., once upon a time, people discussed XCP, RCP, MaxNet, and several more of that nature...  but maybe HPCC is indeed the one that is most realistic to deploy?  Though, that said, it would really be worth taking a longer look at related literature. E.g., HULL might be realistic to deploy in datacenters just as well: 
  https://people.csail.mit.edu/alizadeh/papers/hull-nsdi12.pdf

So, I guess, the question here is: are you asking in general, or (perhaps reasonably so) about HPCC only?


>  Please review the draft and provide feedback.

This draft is a broad overview that asks broad questions - maybe too broad to reasonably discuss them, as almost every question here could be answered with "it depends".
Perhaps you should already make some design decisions of your own and narrow things down a bit.


> Thanks
> Roni Even


Cheers,
Michael

_______________________________________________
iccrg mailing list
iccrg@irtf.org
https://www.irtf.org/mailman/listinfo/iccrg