Re: [T2TRG] Review of draft-irtf-t2trg-iot-edge-03 "IoT Edge Challenges and Functions"

[Roberto Morabito <[e-mail]>]

Hi Xavier and co-authors,

My apologies for the late response on this.
I've checked your answers to my comments and the new text in the draft. Everything looks very good to me!

Once again, I believe that this document represents a very useful and complete source for any IoT Edge-related research.

Thanks for taking into account my comments.

Best Regards,
Roberto


________________________________
From: Xavier De Foy <[e-mail]>
Sent: Tuesday, January 11, 2022 9:36 PM
To: Roberto Morabito <[e-mail]>; [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: RE: Review of draft-irtf-t2trg-iot-edge-03 "IoT Edge Challenges and Functions"


Hi Roberto, thanks again for your thorough review and comments.



Please find our answers below. We also published a revision -04 with related edits (if need be, we will make a new revision, based on follow-up discussions).



Diff: https://www.ietf.org/rfcdiff?url2=draft-irtf-t2trg-iot-edge-04.txt



Best Regards,

Xavier.



From: Roberto Morabito <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, October 21, 2021 02:29
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Review of draft-irtf-t2trg-iot-edge-03 "IoT Edge Challenges and Functions"



Dear Authors,



I have reviewed the "IoT Edge Challenges and Functions" draft.

I found it very interesting and useful on clearly depicting the several aspects connected to this wide research area.



Below, you can find a set of comments that can possibly further strengthening the draft. Hope the authors find these considerations useful.



Cheers,

Roberto



-------------

Section 2.3



"An edge device is any computing or networking resource residing between data sources and cloud-based data centers. In edge computing, end devices not only consume data but also produce data."



– I found this sentence is somehow contradicting the previous one. If edge devices can produce data by themselves, then they are not "any computing or networking resource residing BETWEEN data sources and cloud-based data centers". Maybe the sentence should be modified as "any computing or networking resource residing between end-devices' data sources and cloud-based data centers".



[xdf] Thanks, updated.



"The Industrial Internet Consortium (formerly OpenFog) defines fog computing ..."



– Since a couple of months this consortium has changed name to "Industry IoT Consortium (IIC)"



[xdf] Thanks, updated.



Section 2.4



– In the context of the Smart Factory/Smart Grid/Smart Agriculture use cases, I think that it would be useful to also mention the role played by digital twin systems in such contexts. A related reference to this is e.g., Chen, Baotong, et al. "Edge computing in IoT-based manufacturing." IEEE Communications Magazine 56.9 (2018): 103-10



[xdf] We added some text in section 2.4, as well as your reference and another general reference to digital twins.



– In the Self-driving car use case, it would be useful to understand where the authors see the edge computing taking place. That is, where the edge computing nodes are located in this scenario? On-board Unit of the car? Road-side units? Base stations?



[xdf] Added the text: “In the shorter term we can expect edge computing nodes to be at the base station or in road-side units. However, to further reduce reaction times, some edge computing nodes should be located in the vehicle itself.”



Section 4.1



"Virtualization platforms enable the deployment of virtual edge computing functions (as VMs, application containers, etc.)"



– Wouldn't be better "through VMs, application containers, etc." rather than "as VMs, application containers, etc." ? My assumption is that VMs and containers are simply the means by which edge computing functions can be virtualized, right?



[xdf] Reworded as “using VMs, application containers, etc.”. Hopes this works.



"Stateful computing is supported on platforms hosting native programs, VMs or containers."



– This is a minor thing, but containers were originally conceived to be stateless. The progress of container-related technologies (ex. orchestration frameworks) has enabled the possibility of deploying stateful containers-based systems as well. However, advocates of purely stateless containers maintain that this is still the best and cleanest approach :)



[xdf] Thanks for pointing this out. We added mention of stateless containers in this paragraph: “Stateful computing is supported on platforms hosting native programs, VMs or containers. Stateless computing is supported on platforms providing a "serverless computing" service (a.k.a. function-as-a-service, e.g., using stateless containers), or on systems based on named function networking.”



Section 4.3



– In the second paragraph, I would consider "service discovery" as management component rather than an administration component. Also, I would add "data management" as key functionality of the management component.



[xdf] Discovery tools are classified by RFC 6291 as administrative tools, I assume this classification originates from the use of discovery tools by an administrator, or for the purpose of configuring/managing resources/services. Here this would also comprise the discovery between compute nodes, for the purpose of (self) organization. As you suggest, this should probably not include the discovery of service by endpoints during normal operation, so we updated the text to reflect that. Additionally, we updated the text in 4.3 to mention data management an point to the data management section.



Section 4.3.1



"Broker-based solutions can be used, e.g. using an IoT gateway as a broker to discover IoT resources."



– Broker-based solutions are not the only accepted solutions in the Resource Discovery and Authentication context (I'm thinking of CoAP and LwM2M for example).



[xdf] Thanks, added text and reference to CoAP. Please feel free to provide/update text if needed.



"Today, centralized gateway-based systems rely, for device authentication, on the installation of a secret on IoT end devices and computing devices (e.g., a device certificate stored in a hardware security module)."



– I'm wondering whether an explicit reference to the Trusted Execution Environment activities could help to contextualize better here.



[xdf] text is updated to refer to TEE.



"Discovery, authentication, and trust establishment between end devices, compute nodes, and platforms, with regard to concerns such as mobility, heterogeneity, scale, multiple trust domains, constrained devices, anonymity, and traceability."



– What is heterogeneity referring to here? Connectivity? Hardware? It would be nice to specify it.



[xdf] Heterogeneity in term of hardware and network protocols. The text was modified to "heterogeneous devices and networks".



Section 4.4.1



– In the second paragraph, I think that the concept of edge offloading is too narrowed. For example, it is not mentioned the device-to-edge offloading case. In general, this entire offloading part is not completely clear to me. It seems like the "edge" is designed for simply re-using already existing cloud-based services/technologies. But this is not necessarily true, as edge computing nodes can provide standalone services/functions specifically designed for the edge and without any association with cloud services. Maybe relying only on the oneM2M view, with regards to offloading capabilities, can be limiting.



[xdf] Agreed, oneM2M was just meant be an example, while the previous paragraph included a more (maybe too) general sentence “offloading computation on behalf of a device, service, or user”. Rephrased the paragraph.



Section 4.4.3



"An IoT edge cloud may provide a northbound data plane or management plane interface to a remote network."



– What an IoT edge cloud is? It hasn't been defined earlier in the draft. Does it differ from the "Edge Computing Domain"? Is it complementary to it?



[xdf] Thanks, indeed we defined "edge cloud", but not "IoT edge cloud". We should probably not use this last term, the text is now updated to use simply edge cloud. Edge cloud is defined in 2.3: "Enterprise and campus solutions often interpret edge computing as an "edge cloud", that is, a smaller data center directly connected to the local network (often referred to as "on-premise")."



"Related challenges include:

* Defining edge computing abstractions suitable for users and cloud systems to interact with edge computing systems. In one example, this interaction can be based on the PaaS model [Yangui]"



– I found this part a bit weak. Several orchestration systems already allow to fill the gap in this respect. The challenges here are more related to what the PaaS can provide.  As an example, how the Edge PaaS handles data models heterogeneity?



[xdf] Thank you, updated the text (please feel free to revise/expand on it)? “* Defining edge computing abstractions, such as PaaS [Yangui], suitable for users and cloud systems to interact with edge computing systems, and dealing with interoperability issues such as data models heterogeneity.”



Section 4.4.4



"Protocol translation, analytics, and transcoding may also be performed when necessary."



– It is not completely clear to me what transcoding refers to here.



[xdf] what was meant is, video transcoding, since it is one of the operations that edge computing nodes acting as broker may perform. (Text is now clarified).



Section 4.4.5



– Maybe this sub-section can be merged in other sections. For example, many of these services could easily be included in the OAM context.



[xdf] This text was placed in the in-network-computing section, since these services are potential input for edge computing applications. Hope this works.



Section 4.5.1



"For example, in the context of the oneM2M standard, the software campaign feature enables installing, deleting, activating, and deactivating software functions/services on a potentially large number of edge nodes [oneM2M-TR0052]."



– Is "software campaign feature" a oneM2M thing? What is this about?



[xdf] Yes, this is a oneM2M feature for managing edge computing software updates, described in section 10.2.28.2 in ftp.onem2m.org/Work%20Programme/WI-0002/TS-0001-Functional_Architecture-V4_6_0.DOCX<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-91602b5400986562&q=1&e=01b5de53-c07b-4829-b4e1-c646dd7a5ecf&u=ftp%3A%2F%2Fftp.onem2m.org%2FWork%2520Programme%2FWI-0002%2FTS-0001-Functional_Architecture-V4_6_0.DOCX>. Our goal was to illustrate a set of features. Feel free to provide other examples if you think it can help.



Section 4.5.2



"Addressing concerns such as limited resources, privacy, dynamic and heterogeneous environment, to deploy machine learning at the edge. For example, making machine learning more lightweight and distributed, supporting shorter training time and simplified models, and supporting models that can be compressed for efficient communication [Murshed]."



– I think that this challenge does not concern only ML training -- which is considered often unfeasible in several IoT edge computing contexts -- but also and especially the ML inference.



[xdf] Yes, I think inference was included in this statement ('making machine learning more lightweight and distributed'). Updated the text to clarify this.



Section 5



– Should protocol-based solutions (such as OSCORE) be included in this section?



[xdf] This section is quite high level. We are not sure how to add OSCORE specific considerations, while staying general enough for this kind of document. If you could share some preliminary text, that could help us update the section (unless you are fine with keeping it at high level as is).



-----------



[Banner]

[Banner]<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-6a7f31bfa4141603&q=1&e=01b5de53-c07b-4829-b4e1-c646dd7a5ecf&u=https%3A%2F%2Fwww.interdigital.com%2Ffeatures%2Fsustainability-in-a-wireless-world>

Sustainability in a Wireless World: Research dedicated to understanding the impact of our technologies on the planet.<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-6a7f31bfa4141603&q=1&e=01b5de53-c07b-4829-b4e1-c646dd7a5ecf&u=https%3A%2F%2Fwww.interdigital.com%2Ffeatures%2Fsustainability-in-a-wireless-world>
This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.