[T2TRG] Comments on draft-hong-iot-edge-computing-02

[Frank MATTHIAS KOVATSCH <[e-mail]>]

Dear group and authors

Here are some comments on the document:

> draft-hong-iot-edge-computing

We should rename to draft-hong-t2trg-iot-edge-computing to associate the draft with T2TRG

> 3.2. IoT with Cloud computing

Under Background, maybe rather focus on Cloud Computing alone first (--> "3.2. Cloud Computing")

It would also be good to introduce Edge Computing stand-alone as well before integrating with IoT.

> 3.3. IoT Environmental changes

Instead of already talking about "era of post-Clouds", maybe the background should first simply list the changes IoT brings. However, that would be a duplication of 4. New challenges of IoT.

> 45% of the data created in IoT will be stored, processed, analyzed and acted close to, or at the edge of the network

This is already a prediction of IoT Edge Computing, but it is unclear what led to this prediction. The only argument appears to be users "producing data with their mobile devices".

Overall, I would remove this section from Background and focus on giving well-structures reasons for IoT Edge Computing under 4. New challenges of IoT.

> 4.1. Strict Latency

Maybe extend to "Strict Latency and Jitter", as both is important for deterministic communication.

> few milliseconds

OPC Field-Level Communication expects cycle times down to 32.125 us for motion control systems.

> 4.2. Constrained Network Bandwidth

I would say the constrained network among the devices is not so relevant for Edge Computing. I see an argument in either limited or costly UPLINK bandwidth. Also with Edge Computing, IoT networks will remain constrained, but the required uplink bandwidth can be reduced. Here not the technology is the problem, but the cost of technology providing high bandwidth to remote locations.

> 4.3. Constrained Devices
> It is not practical to require everyone to interact directly with the cloud. This is because these interactions require resource-intensive processing and complex protocols.

Is that so? How would the interaction with an edge node be different? It still needs to be secure and and it was shown that IP is useful and feasible for constrained end-devices...

> 5.1. IoT Data in Edge Computing

The definitions of Edge Computing should be moved to the Background section (also see comment on Edge section above).

> edge/local networks

It would be nice to use the document to define what an edge network is and then drop this slash construct.


> 5.1.2. Data Processing vs 5.1.3. Data Analyzing

Somewhere between these two sections, the document should talk about pre-processing, e.g., feature or metadata extraction, to only transmit a smaller amount of data to the cloud.

> 5.3. Edge Computing in IoT

This has a strong overlap with the previous sections and treats Dirk et al.'s contributions as completely independent work. Since we are all T2TRG, I think it would be nice to merge this to come up with a proper RG document.

> In spite of its benefits, Edge computing in IoT services has challenges such as programmability, naming, data abstraction, service management, privacy and security and optimization metrics.

This is quite hushed while being the meat for us as RG. It would be nice to extend this to a proper "Open Issues" section that results from the New Challenges section. I think Erik's contribution (engineering items vs research topics) can help here a lot.

> Edge computing is increasingly connected to Cloud computing

To my understanding, the term Edge Computing was derived from the concept of Cloud Computing. There always has been local processing, long before the cloud, but there was no specific term. We should clear this up earlier in the Background section.

> relationship of Edge Computing to Cloud Computing

We should be able to define the relationship in the Background section. The interesting part is the split and collaboration, which probably depends on the use case and requires research. (And I think this is also what you meant.)

> 6. Architecture of IoT integrated with Edge Computing

I think it is a bit too early to define an architecture. For instance, there might be edge compute nodes that do not have an uplink but have pure processing roles or control roles such as a SoftPLC.

It might be better to collect the architectures under each use case / use case solution and then derive an overarching architecture later.

> 7. Use Cases of Edge Computing in IoT

I could work on a Smart Manufacturing use case and also offer an editorial pass over the text.

Best wishes,
Matthias