I worked with professor Stefano on Extensible In-band Processing (EIP) which uses a field in the packet to contain data and operations to be performed by the network devices on this data. Data can be provided by the user or collected using in-band telemetry or other means. EIP can be used to support the use cases in your draft and others such as distributed in-band machine learning, semantic routing, detnet, .... etc.
More info on EIP including a draft which describes EIP structure is available in this page: https://eip-home.github.io/eip/ Thanks Hesham On Thu, Apr 27, 2023, 6:36 AM Zhe Lou <[email protected]> wrote: > 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:* 姚柯翰 <[email protected]> > *Sent:* Wednesday, 12 April 2023 06:16 > *To:* Zhangcuimin <[email protected]>; Luigi IANNONE < > [email protected]>; zhouyujing (A) <[email protected]>; Zhe > Lou <[email protected]>; yangjinze <[email protected]> > *Cc:* [email protected]; [email protected] > *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\\)" <[email protected]> > 收件人："[email protected]" <[email protected]>,"[email protected]" <[email protected]> > 抄 送: Zhe Lou <[email protected]> > 发送时间：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: [email protected] <[email protected]> > Sent: 2022年10月24日 9:56 > To: Zhangcuimin <[email protected]>; Luigi IANNONE < > [email protected]>; zhouyujing (A) <[email protected] > >; Zhangcuimin <[email protected]>; Zhe Lou <[email protected]> > 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 > [email protected] > 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: [email protected] <[email protected]> > Sent: 2022年10月24日 9:56 > To: Zhangcuimin <[email protected]>; Luigi IANNONE < > [email protected]>; zhouyujing (A) <[email protected] > >; Zhangcuimin <[email protected]>; Zhe Lou <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
