[Coin] challenges for COIN

"Hejianfei (Jeffrey)" <jeffrey.he@huawei.com> Fri, 01 March 2019 03:40 UTC

Return-Path: <jeffrey.he@huawei.com>
X-Original-To: coin@ietfa.amsl.com
Delivered-To: coin@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6020A131165 for <coin@ietfa.amsl.com>; Thu, 28 Feb 2019 19:40:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 qBFRx-elxWa5 for <coin@ietfa.amsl.com>; Thu, 28 Feb 2019 19:40:39 -0800 (PST)
Received: from huawei.com (szxga02-in.huawei.com [45.249.212.188]) (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 514AB13115F for <coin@irtf.org>; Thu, 28 Feb 2019 19:40:39 -0800 (PST)
Received: from dggeml405-hub.china.huawei.com (unknown [172.30.72.54]) by Forcepoint Email with ESMTP id B83E55C88074679EC035 for <coin@irtf.org>; Fri, 1 Mar 2019 11:40:35 +0800 (CST)
Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.187]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0415.000; Fri, 1 Mar 2019 11:40:33 +0800
From: "Hejianfei (Jeffrey)" <jeffrey.he@huawei.com>
To: "coin@irtf.org" <coin@irtf.org>
Thread-Topic: challenges for COIN
Thread-Index: AdTPzSRTeE5NRFZbTheaw4NmJjVxtg==
Date: Fri, 01 Mar 2019 03:40:33 +0000
Message-ID: <AB07990D3CAE53419132AB701C45693CD6F3DA2E@dggeml529-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.40.78.175]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/coin/a2Ordkk3Wva40WRfMxjbjTo8iBc>
Subject: [Coin] challenges for COIN
X-BeenThere: coin@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "COIN: Computing in the Network" <coin.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/coin>, <mailto:coin-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/coin/>
List-Post: <mailto:coin@irtf.org>
List-Help: <mailto:coin-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/coin>, <mailto:coin-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2019 03:40:42 -0000

Hello COIN,

Some thoughts on the challenges for COIN based on some recent information. You know, challenges are opportunities...

(1) " is in-net compute a wrong direction?"
Now, we have more use cases beyond DCN, such as industrial control networks. But when I was checking the latest Sigcomm CCR yesterday, I noticed that a “negative” paper (below), which concludes that "shoehorning" application semantics into the limited capabilities of programmable switch ASICs is both "unnecessary" and "harmful".  
https://ccronline.sigcomm.org/wp-content/uploads/2019/02/sigcomm-ccr-final266.pdf
Personally, my view is, if the solution has enough benefit, such as speeding up the machine learning by 3 times and nearly no extra cost, there is no reason why it won’t be used in a managed network like DCN or a rack-scale network. But I do agree with this paper in some degree that functions to be implemented into network devices should be less coupled with app semantics, so I wonder we may need better abstraction and less customized for specific applications. A good research topic?

(2) transport, privacy and security
Aaron raised a question how end-to-end privacy and security and the new model of in-network computation can co-exist. But even for the managed networks where privacy and security is not a big problem, we still need something new at the transport layer for in-network compute, for the reasons of reliability to packet loss and congestion control(in a multi-hop network beyond rack). We may have two design choices: let the network device in the middle to react, or leave these tasks to hosts...

(3) what should be COIN's unique role in the edge/fog compute or “cloud continuum”(a good term suggested by Marie-Jose to me)
"Edge" looks promising when nowadays people think about low latency services or offloading some tasks from terminals to the edge/cloud. How can we make difference by leverage the expertise in this community, given that a lot of existing works (open source projects, workshops and events)? It is straightforward that networks are crucial for distributed systems, by definition. But deriving a new network architecture from this, requires re-thinking the relationship or demarcation between compute, data and networking. This could be a big win, but a big challenge as well.

(4) can we have a good abstraction to cover different use cases(from DCN, industrial net to edge/fog etc) and different hardware(from programmable switch, NPU to CPU etc)?
The easiest way is always to catalogue them into groups and address separately, but then, we may miss an opportunity to get a common and generic model and treat each case just an specific case in this model. 

Well, hopefully these questions are enough to have fun in COIN...  

He Jianfei(Jeffrey)  
Innovation . Relevance . Rigor
Huawei Technologies Co.,Ltd.