RE: New draft about In-network Computing Solution

Zhe Lou <zhe.lou@huawei.com> Thu, 27 April 2023 13:36 UTC

Return-Path: <zhe.lou@huawei.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F85CC1522CB; Thu, 27 Apr 2023 06:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLrLETnPgIJd; Thu, 27 Apr 2023 06:36:17 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175D8C151B22; Thu, 27 Apr 2023 06:36:17 -0700 (PDT)
Received: from frapeml500001.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Q6cFh5vFkz6D9Mm; Thu, 27 Apr 2023 21:36:08 +0800 (CST)
Received: from frapeml500004.china.huawei.com (7.182.85.22) by frapeml500001.china.huawei.com (7.182.85.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Thu, 27 Apr 2023 15:36:13 +0200
Received: from frapeml500004.china.huawei.com ([7.182.85.22]) by frapeml500004.china.huawei.com ([7.182.85.22]) with mapi id 15.01.2507.023; Thu, 27 Apr 2023 15:36:13 +0200
From: Zhe Lou <zhe.lou@huawei.com>
To: 姚柯翰 <yaokehan@chinamobile.com>
CC: "rtgwg@ietf.org" <rtgwg@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Subject: RE: New draft about In-network Computing Solution
Thread-Topic: New draft about In-network Computing Solution
Thread-Index: Adl5DQLedXDULr4QRli92dNYQIYYzg==
Date: Thu, 27 Apr 2023 13:36:13 +0000
Message-ID: <d2a29216ccd24a95be543d89aca9c3a0@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.147.214]
Content-Type: multipart/alternative; boundary="_000_d2a29216ccd24a95be543d89aca9c3a0huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/YqF9Pl9NH0cYep_4qZ20sFDZiCo>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Apr 2023 13:36:22 -0000

Dear Kehan,

Many thanks for your comments. I apologize for this late response, as I took a couple of weeks’ vacation. Please see my comments inline.

Regards
David

From: 姚柯翰 <yaokehan@chinamobile.com>
Sent: Wednesday, 12 April 2023 06:16
To: Zhangcuimin <zhangcuimin@huawei.com>; Luigi IANNONE <luigi.iannone@huawei.com>; zhouyujing (A) <zhouyujing3@huawei.com>; Zhe Lou <zhe.lou@huawei.com>; yangjinze <yangjinze@huawei.com>
Cc: rtgwg@ietf.org; sfc@ietf.org
Subject: Re:[sfc] New draft about In-network Computing Solution(draft-zhou-sfc-sinc)

Dear authors,

It's an interesting idea to consider about routing packets to specific network nodes for computation offloading. After reading the draft, I have the following comments:


1.     In-network computing(INC) is closely coupled with applications. It's about implementing application-specific functions inside commercial network devices. In section 5, the draft says  "In the SINC domain, a host MUST be SINC-aware. It defines the data operation to be executed.", I agree with the first sentence, but I think it might not be the case that data operation should be defined by applications, instead, I think these generic computing operations should be pre-defined by network and be open to applications through specific APIs.

[DL] I think we are talking about 2 things, data calculation/operation requested by the application, and data operation capabilities offered by the network node. In the draft, we refer to the former. We do agree that the later is also important, as we briefly mentioned it in the “control plane requirements” section.

To realize successful computation, apart from the definition of computing operations, other related terms should be defined as well, like data types, data structures and calculation precision, etc.  Since the capabilities of network devices provided by different vendors varies a lot, only tranferring computing operations might not be sufficient to perform a successful computation. If these definition can be done by network and encapsulated through common APIs which could be open to applications, and It's more friendly for App developers.

[DL] The same as above, the application tell the network what it wants and the network tells the application what it can.

2.     The control plane requirements in section 8 are a little bit too general, even though specific control plane design is not in the scope of this draft. For example, in bullet one, what kind of resources in switches/routers should be awared? In bullet two, what kind of constraints should be based on for the selection of proper switches/routers to perform INC? These requirements should be more clear, and it might influence the control plane design.

[DL] These are good points. We are going to update the section according to the comments from you and Jeff (from the IETF 116 meeting). If you have suggestions, we may work together on this part.

3.     The computing operations defined in Appendix A are somewhat atomic, and it feels like these operations are not enough for switches/routers to perform successful task offloading. IMHO, as I mentioned in comment 1, INC primitives should be presented through encapsulated APIs that network can open to applications. This might be more realistic.

[DL] According to the discussion in IETF 116, the appendix A will be removed.


Welcome more discussions and I'm very happy to contribute if needed.

Best,
Kehan





----邮件原文----
发件人:"zhouyujing \\(A\\)<file://(A/)>" <zhouyujing3=40huawei.com@dmarc.ietf.org<mailto:zhouyujing3=40huawei.com@dmarc.ietf.org>>
收件人:"rtgwg@ietf.org<mailto:rtgwg@ietf.org>" <rtgwg@ietf.org<mailto:rtgwg@ietf.org>>,"sfc@ietf.org<mailto:sfc@ietf.org>" <sfc@ietf.org<mailto:sfc@ietf.org>>
抄 送: Zhe Lou  <zhe.lou@huawei.com<mailto:zhe.lou@huawei.com>>
发送时间:2022-10-28 16:36:57
主题:[sfc] New draft about  In-network Computing Solution(draft-zhou-sfc-sinc)

Hi all,

We submitted a new draft about In-Network Computing (https://datatracker.ietf.org/doc/draft-zhou-sfc-sinc/). In this draft, we want to discuss a mechanism "Signaling In-Network Computing operations" (SINC) to enable in-packet operation signaling for in-network computing for specific scenarios.

Hope to get your review and comments.

Many thanks!

Best,
Yujing Zhou

-----Original Message-----
From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Sent: 2022年10月24日 9:56
To: Zhangcuimin <zhangcuimin@huawei.com<mailto:zhangcuimin@huawei.com>>; Luigi IANNONE <luigi.iannone@huawei.com<mailto:luigi.iannone@huawei.com>>; zhouyujing (A) <zhouyujing3@huawei.com<mailto:zhouyujing3@huawei.com>>; Zhangcuimin <zhangcuimin@huawei.com<mailto:zhangcuimin@huawei.com>>; Zhe Lou <zhe.lou@huawei.com<mailto:zhe.lou@huawei.com>>
Subject: New Version Notification for draft-zhou-sfc-sinc-00.txt


A new version of I-D, draft-zhou-sfc-sinc-00.txt has been successfully submitted by Yujing Zhou and posted to the IETF repository.

Name: draft-zhou-sfc-sinc
Revision: 00
Title: Signaling In-Network Computing operations (SINC)
Document date: 2022-10-23
Group: Individual Submission
Pages: 19
URL:            https://www.ietf.org/archive/id/draft-zhou-sfc-sinc-00.txt
Status:         https://datatracker.ietf.org/doc/draft-zhou-sfc-sinc/
Html:           https://www.ietf.org/archive/id/draft-zhou-sfc-sinc-00.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-zhou-sfc-sinc


Abstract:
   This memo introduces "Signaling In-Network Computing operations"
   (SINC), a mechanism to enable in-packet operation signaling for in-
   network computing for specific scenarios like NetReduce,
   NetDistributedLock, NetSequencer, etc.  In particular, this solution
   allows to flexibly communicate computation parameters to be used in
   conjunction with the packets' payload, to signal to in-network SINC-
   enabled devices the computing operations to be performed.




The IETF Secretariat



_______________________________________________
rtgwg mailing list
rtgwg@ietf.org<mailto:rtgwg@ietf.org>
https://www.ietf.org/mailman/listinfo/rtgwg

Subject:[sfc] New draft about  In-network Computing Solution(draft-zhou-sfc-sinc)

Hi all,

We submitted a new draft about In-Network Computing (https://datatracker.ietf.org/doc/draft-zhou-sfc-sinc/). In this draft, we want to discuss a mechanism "Signaling In-Network Computing operations" (SINC) to enable in-packet operation signaling for in-network computing for specific scenarios.

Hope to get your review and comments.

Many thanks!

Best,
Yujing Zhou

-----Original Message-----
From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Sent: 2022年10月24日 9:56
To: Zhangcuimin <zhangcuimin@huawei.com<mailto:zhangcuimin@huawei.com>>; Luigi IANNONE <luigi.iannone@huawei.com<mailto:luigi.iannone@huawei.com>>; zhouyujing (A) <zhouyujing3@huawei.com<mailto:zhouyujing3@huawei.com>>; Zhangcuimin <zhangcuimin@huawei.com<mailto:zhangcuimin@huawei.com>>; Zhe Lou <zhe.lou@huawei.com<mailto:zhe.lou@huawei.com>>
Subject: New Version Notification for draft-zhou-sfc-sinc-00.txt


A new version of I-D, draft-zhou-sfc-sinc-00.txt has been successfully submitted by Yujing Zhou and posted to the IETF repository.

Name: draft-zhou-sfc-sinc
Revision: 00
Title: Signaling In-Network Computing operations (SINC)
Document date: 2022-10-23
Group: Individual Submission
Pages: 19
URL:            https://www.ietf.org/archive/id/draft-zhou-sfc-sinc-00.txt
Status:         https://datatracker.ietf.org/doc/draft-zhou-sfc-sinc/
Html:           https://www.ietf.org/archive/id/draft-zhou-sfc-sinc-00.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-zhou-sfc-sinc


Abstract:
   This memo introduces "Signaling In-Network Computing operations"
   (SINC), a mechanism to enable in-packet operation signaling for in-
   network computing for specific scenarios like NetReduce,
   NetDistributedLock, NetSequencer, etc.  In particular, this solution
   allows to flexibly communicate computation parameters to be used in
   conjunction with the packets' payload, to signal to in-network SINC-
   enabled devices the computing operations to be performed.




The IETF Secretariat



_______________________________________________
rtgwg mailing list
rtgwg@ietf.org<mailto:rtgwg@ietf.org>
https://www.ietf.org/mailman/listinfo/rtgwg