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

Michael Welzl <michawe@ifi.uio.no> Mon, 04 November 2019 07:59 UTC

Return-Path: <michawe@ifi.uio.no>
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 28E671200D5 for <iccrg@ietfa.amsl.com>; Sun, 3 Nov 2019 23:59:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 z40sgPny6c2d for <iccrg@ietfa.amsl.com>; Sun, 3 Nov 2019 23:59:44 -0800 (PST)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 566101200B9 for <iccrg@irtf.org>; Sun, 3 Nov 2019 23:59:44 -0800 (PST)
Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <michawe@ifi.uio.no>) id 1iRXH4-0000H2-09 for iccrg@irtf.org; Mon, 04 Nov 2019 08:59:42 +0100
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx10.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92.3) (envelope-from <michawe@ifi.uio.no>) id 1iRXH3-000546-AO for iccrg@irtf.org; Mon, 04 Nov 2019 08:59:41 +0100
From: Michael Welzl <michawe@ifi.uio.no>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 04 Nov 2019 08:59:40 +0100
References: <6E58094ECC8D8344914996DAD28F1CCD23D9DC0C@dggemm526-mbx.china.huawei.com>
To: iccrg IRTF list <iccrg@irtf.org>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD23D9DC0C@dggemm526-mbx.china.huawei.com>
Message-Id: <24030CAE-F96B-4EB2-B36F-28534D413C05@ifi.uio.no>
X-Mailer: Apple Mail (2.3445.9.1)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 08AE77EFC47A441947910C292B2AFFA0FC118C97
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/2q1Ssql6FYXUGL3QOdF0hXZTO88>
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: Mon, 04 Nov 2019 07:59:47 -0000

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