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

[Matthias Kovatsch <[e-mail]>]

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.


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

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.


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


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

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

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