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

Alessandro Bassi <alessandro@bassiconsulting.eu> Tue, 02 April 2019 10:44 UTC

Return-Path: <alessandro@bassiconsulting.eu>
X-Original-To: t2trg@ietfa.amsl.com
Delivered-To: t2trg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE240120033 for <t2trg@ietfa.amsl.com>; Tue, 2 Apr 2019 03:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-BoBYMA0t93 for <t2trg@ietfa.amsl.com>; Tue, 2 Apr 2019 03:43:58 -0700 (PDT)
Received: from m-r1.th.seeweb.it (m-ra.th.seeweb.it [5.144.164.173]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C746112004E for <t2trg@irtf.org>; Tue, 2 Apr 2019 03:43:57 -0700 (PDT)
Received: from [192.168.1.166] (unknown [37.143.118.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by m-r1.th.seeweb.it (Postfix) with ESMTPSA id 6D9DC2162E; Tue, 2 Apr 2019 12:43:54 +0200 (CEST)
From: Alessandro Bassi <alessandro@bassiconsulting.eu>
To: yghong@etri.re.kr, t2trg@irtf.org
Message-ID: <06b11fde-2ec6-2c31-8a1a-390ebd158a2d@bassiconsulting.eu>
Date: Tue, 02 Apr 2019 12:43:53 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------D377CF453BA6B3F67A8031A0"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/t2trg/4NXX0M6Bm7EUlRpgT51kd3tYZyw>
Subject: [T2TRG] Comments on draft-hong-iot-edge-computing-02
X-BeenThere: t2trg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Thing-to-Thing Research Group <t2trg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/t2trg>, <mailto:t2trg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/t2trg/>
List-Post: <mailto:t2trg@irtf.org>
List-Help: <mailto:t2trg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/t2trg>, <mailto:t2trg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2019 10:44:03 -0000

Dear authors

I've read this draft and I also have a few comments:

1. Introduction

"Nowadays, most IoT services are based on Cloud computing since it can
provide virtually unlimited storage and processing power."

Do you have any statistics to show that really most of IoT services are
on the cloud?

"about a half of data is stored, processed, analyzed and acted upon
close to the data producer"

Again, can you quote a source for this claim?

3.

I think you should introduce a definition of Edge computing and Cloud
computing here rather than Section 5, together with the definition of
Fog (and Mist maybe?).

3.1

In your definition, IoT does not have any actuation - do you really mean
it? As there are dozens of definitions for IoT, I would recommend maybe
to pick one of the existing ones.

3.2

"IoT is generally characterized by real world small things that are
widely distributed but have limited storage and processing power"

RFC 7228 defines the terminology for constrained nodes (and networks).

3.3

In general, it is not clear to me the aim of this paragraph. You already
stated that the massive amount of data generated by IoT Devices will
need to be processed at the edge. This architecture for sure makes
sense, but it's not new. I don't see any "paradigm shift". Unless you
have some data that shows that until 20XX the YY% of all IoT application
were using dummy sensors and actuators, and the actual processing was
taking place remotely, while the trend in the last ZZ years is that the
processing is happening "closer" to the data collection points - but in
this case you would need to explicitly write the source. As well, there
is the need of defining the closeness (on device? on some intranet
directly connected to the device? etc etc ...).

"Now with IoT, we will reach the era of post-Clouds where unprecedented
volume and variety of data will be generated by things at edge networks
and many applications will be deployed on the edge netwoks to consume
these IoT data."

Is this your opinion?

"Some of the applications may have very short response times, some may
contain personal data, and others may generate vast amounts of data.
Today's Cloud based service models are not suitable for these applications."

Why? 

4.1

"These requirements for latency are difficult to achieve by today's
Cloud services."

No. IMO it's simply impossible. IP is a connectionless, unreliable
protocol by definition. IoT applications may require hard-real time
response time, which, from the engineering point of view, it's not
possible to guarantee over an IP layer.

4.2

"With an exponential rate, IoT data is generated by the massive things
[...] "

what do you mean by massive things?

"connected into the Internet [Kelly]
<https://tools.ietf.org/id/draft-hong-iot-edge-computing-01.html#Kelly>
and extremely high network bandwidth is required to send all the data to
the cloud."

Do you have any data to show? What are the bandwidth requirements?

"Since 90% of the IoT data generated by the endpoints will be stored and
processed locally rather than in the cloud [...]"

Do you have any study to back this claim?

"[...] sending all the IoT data to the cloud is often unnecessary."

well, if it's already processed, indeed it makes no sense to send it ...
I think this sentence should be rephrased.

"Or sometimes it is prohibited due to regulations and data privacy
concerns."

Can you make any example?

4.3

"Many IoT things such as sensors, data collectors, actuators,
controllers, cars, drones, etc., have very limited hardware resources."

I'm not quite sure that a car has very limited hardware resources ...

In general, what is an "IoT Thing"?

 "Many constrained IoT things cannot rely solely on their limited
resources to meet all their computing needs."

There's a flaw IMO in this concept. Assuming that for "IoT things" you
mean "device", if I am a company developing some devices I have a clear
business idea (or at least I should). If _as an example _ I am selling
cameras, I might choose to embed processing power on the camera itself
for image recognition, or else just transmit the images to an endpoint,
on the cloud or wherever. The "computing need" here seems linked to a
specific service (such as, detecting bad guys into a crown of people).
The device itself does not have any computing need: it may have some
computing functionality, and expose some resources (such as doing facial
image recognition on-device), but per se it has no needs. Therefore, you
should rephrase the sentence such as

'Many Class <you choose the class here according to RFC 7228> and below
devices do not have the processing capabilities to fulfill the needs of
complex services'.

"It is not practical to require everyone to interact directly with the
cloud."

The cloud here is the Internet?

"This is because these interactions require resource-intensive
processing and complex protocols."

I would disagree. IMO the main reason why a centralized architecture has
issues is for scalability. While I can connect a limited number of
constrained resources to a service running on some cloud, scaling up the
number poses obvious issues of network traffic and processing. If I have
cameras transmitting videos to a server, once the channel is set up,
there is no resource-intensive processing nor complex protocols - no
more that if a camera processes the image itself and send an interrupt
every time a bad guy is detected.

4.4

"Cloud services will have difficulty providing uninterrupted services to
devices and systems such as vehicles, drones, and oil rigs that have
intermittent network connectivity to the cloud."

I'm sure the 5G guys will disagree with this ... :)

4.5

"When IoT data is sent to the cloud which is the end point in the
traditional end-to-end communication system, privacy of the data is a
challenge since it may travel across multiple routers to the cloud."

that's why data is encrypted ... right?

5.1

In general, there are two different architectures:

- centralised one, with dummy endpoints and all processing done at the
"core".

- decentralised one, with processing done (in all or in part) at the
edge and only relevant data passed to the core.

This draft is making the point that the second architecture is better,
for a number of reasons. That is fine. What needs to be clear though is
why is better, under which conditions ASO. The text here does not give
any proof of this being the case.

5.1.1

"As tremendous IoT sensors, IoT actuators, and IoT devices [...]"

Tremendous?

In my view, a Device IS A sensor or an actuator. Here you list the
three, so what is a device in this context?

"[...] are connected to the Internet, IoT data volume from these things
are expected to increase explosively."

why? Besides, usually a Device is not directly connected to the
Internet. A temperature sensor is just connected to a proxi. A smart
shoe is just connected to a smart phone via BLE. Usually, constrained
devices do not have enough "power" to hold a complete Internet stack,
and they are connected to a gateway.

"And it is expected that much of this high volume of IoT data is
produced and/or consumed within edge networks, not to traverse through
cloud networks."

Do you have any source for this?

Besides, why it should "traverse" cloud networks?

" Until now, mainly IoT data generated IoT things are transferred and
accumulated in a remote server and to store IoT data in a remote server
requires expensive cost of transmission and storage."

Do you have any source for this? 

"To mitigate the cost of transmission and storage, it is required to
divide IoT data into two types of data; one is stored in edge networks
and the other is stored in cloud networks."

According to which criteria data may be stored on the edge or transferred?

5.1.3

"If it is possible to separate IoT data in edge networks and cloud
networks,"

While it's possible to interpret this sentence, if your aim is to say
that data generated by IoT devices can be stored and processed either at
the edge or at the core, I think it would be better to rephrase as such.

"Edge computing can do more functions with IoT data in edge networks.
Because Edge computing has the capabilities to handle IoT data in edge
networks, it is also possible to analyze IoT data to provide enhanced
IoT services such as intelligence."

This is really not clear to me.

6

In general, I think the use cases as they are stated are rather weak. I
would omit this section unless there are specific data to be shown. I
make an example for the smart construction: you write that today there
is a certain amount of data that can be recorded and sent to a remote
service for processing, and this has a cost (LTE and AWS). Indeed - but
it's not that deploying a gateway on a construction site (or nearby)
comes for free. Statistical analysis and ML can be applied on a remote
server - actually, as the remote server is likely to be more powerful
and has access to a larger number of data sets, the ML algorithm may
work better from remote than on the edge. The communication time - given
a decent connectivity - is irrelevant given the likely "latency time" of
the inspector. On the other hand, if you can make a precise claim on
cost saving, or on scalability over certain numbers of connected
devices, then it's probably good to have a section outlining the
boundaries in specific use cases over which a distributed architecture
has clear advantages.

thanks! best,

--alex