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

[Xavier de Foy <[e-mail]>]

Hi Milan, thanks again for your comments, we have published a new version
-02 of the draft.

 In addition to addressing your comments (see details below), we also added
new references to papers, and related text, in 4.{3,4,5} research
challenges sections and 4.6 emulation/simulation, and did minor edits
across the whole document.



[MM] 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.

[authors] re-wrote the smart construction use case and deleted the smart
water system one. Reordered some use cases.

[MM] 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”.

[authors] changed the title to Connectivity Cost and replaced 'many' with
'some'.

[MM] 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.

[authors] thanks, we added some text based on your comment in section 4.1
(which describes IoT EC today), which should be a good fit for this
information, so that we can keep section 3.3 limited to list IoT
requirements including the need for reliable, uninterrupted, or resilient
service.

[MM] 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.

[authors] we have moved/updated/renamed the virtualization management
section (now Multi-Tenancy and Isolation) - External APIs (now
northbound/southbound communication) - Data Management (adding “and
Analytics”). Reordered some sections to bring more general/important
sections first. We also made some updates in the text and added a few new
references.

[MM] 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.

[authors] updated section 4.4.2. (was 4.4.4) with storage/caching
distinction

[MM] Use of acronyms – I would suggest spelling out of acronyms when first
used.

[authors] thanks, we added some explicit spelling of acronyms.

Best Regards,

Xavier (on behalf of the draft co-authors)

~~~~~~~~~~~~~~~~~~~~~~~

A new version of I-D, draft-irtf-t2trg-iot-edge-02.txt has been
successfully submitted by Xavier de Foy and posted to the IETF repository.



Name:                  draft-irtf-t2trg-iot-edge

Revision:              02

Title:                      IoT Edge Challenges and Functions

Document date:               2021-05-02

Group:                  t2trg

Pages:                   30

URL:
https://www.ietf.org/archive/id/draft-irtf-t2trg-iot-edge-02.txt

Status:         https://datatracker.ietf.org/doc/draft-irtf-t2trg-iot-edge/

Htmlized:
https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-iot-edge

Htmlized:       https://tools.ietf.org/html/draft-irtf-t2trg-iot-edge-02

Diff:
https://www.ietf.org/rfcdiff?url2=draft-irtf-t2trg-iot-edge-02



Abstract:

   Many IoT applications have requirements that cannot be met by the

   traditional Cloud (aka cloud computing).  These include time

   sensitivity, data volume, connectivity cost, operation in the face of

   intermittent services, privacy, and security.  As a result, the IoT

   is driving the Internet toward Edge computing.  This document

   outlines the requirements of the emerging IoT Edge and its

   challenges.  It presents a general model, and major components of the

   IoT Edge, to provide a common base for future discussions in T2TRG

   and other IRTF and IETF groups.






On Tue, Mar 23, 2021 at 7:21 PM Milan Milenkovic <[e-mail]> wrote:

> 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, [phone]
>
>
> _______________________________________________
> T2TRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/t2trg
>