[T2TRG] Some comments and suggestions on IoT Edge Challenges and Functions

[Milan Milenkovic <[e-mail]>]

Hi all,

I just completed a studious read of  IoT Edge Challenges and Functions, draft-irtf-t2trg-iot-edge-01. If it is still subject to revisions, I have a few comments and suggestions below (in chronological order, not the order of importance):

  *   Use cases, Section 2.4 - some of them highlight the benefits of edge computing, such as the smart grid (latency and local autonomy), smart agriculture (connectivity "in the wild" challenges), self-driving car (latency and local autonomy of operation when disconnected). However, some others, like smart construction and smart water system, feel a bit generic and as described do not seem to exemplify the need for edge processing. I suggest revamping or dropping of those.
  *   Section 3.3 - While most of the IoT traffic flow tends to be "upstream", I think that the availability and cost of connectivity can be challenging in various IoT settings and suggest retitling and recasting this section as Connectivity Cost. It also states that many IoT deployments are not challenged by constrained network bandwidth, citing Wi-Fi 6 and 5G links. Since those are not yet widely deployed or suitable for a variety of IoT installations, I suggest changing "many" to "some".
  *   Section 3.3 - I think the section would benefit from mentioning that resilience in IoT often entails the ability to operate autonomously in periods of disconnectedness in order to preserve the integrity and safety of the controlled system, possibly in a degraded mode. It might be useful to add that IoT devices and gateways are often expected to operate in the always-on and unattended mode, thus adding design challenges of fault detection and unassisted recovery to operational states.
  *   Section 4 -  Should be revised to separate description of edge functions from the implementation mechanisms. For example, virtualization is an implementation mechanism that may be used to improve security by isolation and to support multi-tenancy but it is not an IoT-related function of the edge. I suggest dividing the description into key IoT functions of the edge - such as the southbound data acquisition and command management, northbound communication and optional local event processing, storage, control, and analytics. Perhaps making the distinction between the listed data-plane functions and control-plane functions, such as node operational and security management might also be beneficial. Virtualization, containers, and external API may then be described as beneficial or common implementation mechanisms.
  *   Section 4.4.4 - IMO caching generally refers to temporary storage to improve performance with no persistence guarantees. The section should clarify that the edge node may offer local data storage (persistence subject to retention policies), caching (anticipatory best effort), or both.
  *   Use of acronyms - I would suggest spelling out of acronyms when first used.

Regards,
Milan Milenkovic, Principal
IoTsense LLC, www.iotsense.com<http://www.iotsense.com/>, [phone]