Re: [T2TRG] New Version Notification for draft-hong-t2trg-iot-edge-computing-01.txt

[Rute Sofia <[e-mail]>]

Dear Matthias,

thanks for the feedback.

inline, still a few comments…

From: Matthias Kovatsch <[e-mail]>
Sent: 26 November 2019 12:13
To: Rute Sofia <[e-mail]>; Jungha Hong <[e-mail]>; [e-mail]
Subject: RE: New Version Notification for draft-hong-t2trg-iot-edge-computing-01.txt

Dear Rute

Thank you for your interest and input. We (the authors) had a meeting at IETF 106 to discuss the way forward and also talked about your e-mail. Please find our comments inline:


-          3.3, Edge Computing, the title should go for Edge/Fog computing (which anyway is referenced in the text)

We want to avoid such slashed terms in the document, especially in the title (and we have a todo to further fix the current document in this regard). Overall, Edge has many different meanings depending on the background and we agreed that it also includes multi-tiered approaches. We will include the term “Fog” in the background section on Edge Computing to clarify.


-          4. Additional challenges not mentioned:

o   Energy consumption

o   Handling both event-driven and time-driven traffic (you mention latency and jitter, but speak mostly about deterministic aspects)

Energy consumption is actually not that big a problem when going from IoT to IoT Edge Computing. The whole point is to have less constrained devices close to the physical objects.

For the traffic types, we maybe need a clarification what new challenge you have in mind.

In IoT, we have also even-driven traffic, e.g., alarms. If we think about deterministic scheduling, then this type of traffic will be handled as BE (or, we need a mechanism before that can place it in a QoS class to handle more “urgent” traffic.



-          5. The definition of what the edge is/can be is missing. The edge can be a complex device co-located to a BS, on a shop-floor. But it can also be a smartphone. There is the need to define this in the context being provided.

This is in line with the missing background on Edge Computing and the different models/patterns (slash here because we also have a todo on deciding on our own terminology) we want to document. It was more a time problem in particular on my side to work on the background section.


-           The document provides (Figure 1) a centralized version of the edge computing manager.  It would be good to consider a second figure, with a de-centralized version.

The figured was changed to logical functions, hence there were no assumptions about implementation (e.g., centralized vs distributed). We decided to replace the figure anyway and follow a step-by-step introduction of models/patterns from simple to more complex.


-          5.3, the edge computing functions should also include the relevant abstraction functions, e.g., semantic interoperability; data aggregation, etc.

We do not see interoperability as a function; there can be translation functions to connect devices from different ecosystems (usually called gateway).

Ok, you are then assuming just translation from protocols? What about services and apps? Interoperability “management” could be a function…


Data aggregation should indeed be mentioned in more detail under the storage and data functions.


-          5.4, stating that the edge computing domain should directly or indirectly control the network functions (of the data exchange) is reducing the possibility of having an autonomous, self-organizing behaviour between edge computing nodes.

We see this again more as an implementation aspect, centralized vs distributed. Overall, there needs to be function to provide control over the network.

Hum, perhaps I am not reading this right…imagine an “edge” based on a crowd-sensing infrastructure (in other words, an opportunistic wireless environment). The control has to be decentralised, or at least part of it, correct?


-          6.1, the computing aspects and protocols mentioned should consider or cite work that are relevant both from a consumer and an industrial perspective. OPC-UA must be mentioned; and other relevant protocols are DDS.

Full completeness is hard to achieve and the current examples in the appendix are rather input for the writing phase – we probably remove it completely because of the issue of always missing something. If you have concrete functions or models in mind that OPC UA introduces, we are happy to include them at the abstract level.

Hum, in section 6.1 you specifically mention CoAP and MQTT. Which are not the preferred protocols in Industrial IoT environments. From an abstraction perspective, the different is the broker-based pubsub model used by MQTT; the client/server architecture used by CoAP; and the PubSub approach of OPC-UA…or in other interesting (architectural) approaches, e.g., ICN…



-          6.1, this section is not really also clear…this seems to describe a set of services which are today common to any edge platform, but seems to be quite incomplete…

The original idea was to have a structure for investigating the state of the art, which is listed in more detail in the (to be removed) appendix. We have a todo to better align sections 5 and 6.


-          6.2 Likewise for this section. Perhaps it should be split into consumer and Industrial IoT, and for each category, then address specific and relevant use-cases, as well as provide pointers to prior work on this

Our hope is the talk about models and functions that can apply for both.


Ultimately, we would like to get an idea which models and functions are already well covered by the state of the art and where there are white spots that can be addressed by the IETF.

Yes, and this is a great contribution. However, IMO the focus should not forget the largest market share of IoT, which is IIoT…so when considering the computational abstraction of edge computing, it is relevant to ensure that this is also being covered…

Thanks again for your input. It helped to define the direction and decide on the todos. As mentioned in the T2TRG summary meeting, we plan to have an improved version of the draft by Christmas and would be very happy to have another review from you some time before the next IETF meeting (with enough time to have another iteration ready at IETF 107).

Sure,
Rute
Best wishes,
Jungha, Yong-Geun, Xavier, Matthias, Eve, and Dirk