Re: [iccrg] New draft submitted for draft-pan-tsvwg-hpccplus-02.txt

Michael Welzl <michawe@ifi.uio.no> Tue, 15 December 2020 07:24 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 6F9793A0B89 for <iccrg@ietfa.amsl.com>; Mon, 14 Dec 2020 23:24:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=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 xGxKsNxk1TD0 for <iccrg@ietfa.amsl.com>; Mon, 14 Dec 2020 23:24:17 -0800 (PST)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 3E6283A0B87 for <iccrg@irtf.org>; Mon, 14 Dec 2020 23:24:16 -0800 (PST)
Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from <michawe@ifi.uio.no>) id 1kp4gt-0006iO-D1; Tue, 15 Dec 2020 08:24:11 +0100
Received: from ti0182q160-1994.bb.online.no ([212.251.170.224] helo=[192.168.1.11]) by mail-mx10.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from <michawe@ifi.uio.no>) id 1kp4gr-0004yV-5T; Tue, 15 Dec 2020 08:24:11 +0100
From: Michael Welzl <michawe@ifi.uio.no>
Message-Id: <7ADC7D48-26A4-4446-A423-A3A6F1536B4A@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9A69129C-CE65-42DD-B9D5-BB5A0DD5C763"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Tue, 15 Dec 2020 08:24:06 +0100
In-Reply-To: <3b396b85-d412-4e52-8716-52eac2a814e8.miao.rui@alibaba-inc.com>
Cc: iccrg <iccrg@irtf.org>, "Pan, Rong" <rong.pan@intel.com>, "\"Liu, Hongqiang(洪强)\"" <hongqiang.liu@alibaba-inc.com>, "jri.ietf" <jri.ietf@gmail.com>, "Lee, Jeongkeun" <jk.lee@intel.com>, Barak Gafni <gbarak@mellanox.com>, Yuval Shpigelman <yuvals@mellanox.com>
To: "Rui, Miao" <miao.rui@alibaba-inc.com>
References: <3b396b85-d412-4e52-8716-52eac2a814e8.miao.rui@alibaba-inc.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 212.251.170.224 is neither permitted nor denied by domain of ifi.uio.no) client-ip=212.251.170.224; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.11];
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.011, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 9C5884DB37D0D7EDED5E97FA35A2B123459A94AE
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/-LOsM8YpKux-Hbrn2uhXaMm-X04>
Subject: Re: [iccrg] New draft submitted for draft-pan-tsvwg-hpccplus-02.txt
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: Tue, 15 Dec 2020 07:24:20 -0000

Hi !

In this world of research, I do want to comment that the signaling protocol looks extremely similar to what I came up with in my Ph.D. thesis. This paper from 2005 describes it:
Michael Welzl: "Router Aided Congestion Avoidance with Scalable Performance Signalling", KiVS 2005 (Kommunikation in verteilten Systemen), Kaiserslautern, Germany, 28 February - 2 March 2005, Springer-Verlag. https://folk.universitetetioslo.no/michawe/research/publications/kivs2005.pdf
I made this overview page in 2006, still alive:  https://folk.universitetetioslo.no/michawe/research/projects/ptp/index.html

Back then, everyone told me that this is completely undeployable  :-)   but this was before data centers became the big thing they are today, and before there were network cards supporting this kind of thing.

Indeed, such mechanisms are simply no fit for the Internet’s end-to-end congestion control - but they should be deployable on path segments, with PEPs at the edge, like here:  https://www.isi.edu/isi-xcp/docs/kapoor-pep-gi2005.final.pdf

Cheers,
Michael


> On Dec 15, 2020, at 1:11 AM, Rui, Miao <miao.rui@alibaba-inc.com> wrote:
> 
> Hello ICCRG members,
> 
> Alibaba, Intel, and Mellanox have worked on an INT-based High Precision Congestion Control algorithm: HPCC++. We have posted an initial draft that can be found at
> https://www.ietf.org/id/draft-pan-tsvwg-hpccplus-02.txt <https://www.ietf.org/id/draft-pan-tsvwg-hpccplus-02.txt>
> 
> The key design choice of HPCC++ is to use inband telemetry to provide fine-grained load information, such as queue size and accumulated tx traffic to compute precise flow rates. This has two major benefits:
> 1. HPCC++ can quickly converge to proper flow rates to highly utilize bandwidth while avoiding congestion;
> 2. HPCC++ can consistently maintain a close-to-zero queue for low latency.
> 
> We would love to hear your comments and feedback.
> 
> Best regards,
> 
> Rui Miao
> _______________________________________________
> iccrg mailing list
> iccrg@irtf.org
> https://www.irtf.org/mailman/listinfo/iccrg