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

[Roberto Morabito <[e-mail]>]

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".


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

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

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

– 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?

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?


"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 :)

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.

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).


"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.


"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.

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.

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?


"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?

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.

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.

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?

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.

Section 5

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

-----------