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

From: Alessandro Bassi <[email-masked]>
Date: Tue, 2 Apr 2019 12:43:53 +0200

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

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 2 Apr 2019 13:00:43 +0200

Dear Alessandro,

> and they are connected to a gateway.

Well, there are different classes of constrained devices [RFC 7228,
draft-bormann-lwig-7228bis-04].

>From RFC 7228, regarding Class 1 devices:

   "... are capable enough to use a
   protocol stack specifically designed for constrained nodes (such as
   the Constrained Application Protocol (CoAP) over UDP [COAP]) and
   participate in meaningful conversations without the help of a gateway
   node."

You are right that there are devices which are more constrained than Class
1 ones (i.e. Class 0 devices). These match the category you just
described.

On another topic, please note that there is support for IPv6 over BLE.
This comprises the star network topology [RFC 7668] and extended (e.g.
mesh) topologies [draft-ietf-6lo-blemesh].

Thanks,

Carles

---

From: Alessandro Bassi <[email-masked]>
Date: Tue, 2 Apr 2019 13:08:26 +0200

Dear Carles,

indeed, you are right: in my comment I should have specified the Device
class I was referring to.

thanks! best,

--alex

---

From: 홍용근 <[email-masked]>
Date: Wed, 3 Apr 2019 14:00:06 +0000

Hi. Alex.

Thanks a lot for your comments.
With respect to all your comments on the lack of the evidence data or references, we will clarify them in the next revision.
Other than that, please find the answers in-line.

Best regards.

Yong-Geun.

From: Alessandro Bassi [mailto:[email-masked]]
Sent: Tuesday, April 2, 2019 7:44 PM
To: 홍용근; [email-masked]
Subject: Comments on draft-hong-iot-edge-computing-02

Dear authors

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"

[Hong] We think this is a common sense and it is easy to predict.

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

[Hong] We are thinking of having individual sections or subsections on Edge computing and Cloud computing as Matthias suggested by the mailing list.

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.

[Hong] IoT could include sensors, devices, and actuators.  We tried to provide very general concept of IoT since there are dozens of definitions as you said.

3.2

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

[Hong] We will take a look at RFC 7228. And, Carles already responsed it.

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?

[Hong] Don’t you agree with it? Or are you asking the source as well? We will clarify this as well in the next revision.

"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?

[Hong] Do you think that today's Cloud based service can satisfy any IoT applications which even requires very short response times and privacy? Or asking a source again? We don’t catch what you are asking.

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.

[Hong] In some point, you are right. We tried to focus the distance between the provider of data and the consumer. As you know, the long distance between communication nodes will make delay.

4.2

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

[Hong] Since we stated in subsection 3.1, things are various embedded systems such as home appliances, mobile equipment, wearable devices, etc. We may change “massive” to “numbers of”.

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

[Hong] We thought that it was very trivial that sending all the IoT data to the cloud  requires high network bandwidth since the generating IoT data is massive. We will try to include more specific data on this in the next revision.

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

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

[Hong] IMO, depending on service, IoT data may be sent to cloud even though it is already processed at edge.

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

[Hong] It could be possible in healthcare service. We may modify “it is prohibited” to “it MAY BE prohibited”.

4.3

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

[Hong] Yes, cars have more enhanced hardware resources compared to others. We will delete “cars” there.

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

[Hong] No. We meant it cloud.

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

[Hong] We will clarify this as your comments in the next revision.

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

[Hong] In some point, you are right. But, in real circumstances, not only 5G, but also 2G, 3G, 4G and other wireless technologies could be used for IoT services.

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

[Hong] Yes, the encryption is a solution for the privacy issue. In this draft, we discuss the challenges which does not mean that there is no solution for those.

5.1

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

[Hong] We will clarify this in the next revision.

5.1.1

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?

[Hong] We will revise the sentence.

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

[Hong] You can find many future prediction of IoT services and traffic volumes. And we also believe this situation and we have tried to prepare this problem.

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

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

[Hong] It depends on IoT services. Some IoT data will be consumed at the edge and some IoT data will be delivered to cloud.

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

[Hong] Thanks for your suggested text. It looks better. We will reflect this in a next revision

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.

[Hong] I agree that the use cases are rather weak. Because we are implementing some trial services and products, there are limitation. During the progress our implementation, we will add more practical and specific use cases. If you have a relevant information, it is appreciate to provide texts.

thanks! best,

--alex

---

From: Alessandro Bassi <[email-masked]>
Date: Thu, 4 Apr 2019 15:51:32 +0200

Hi Yong-Geun,

Thank you for your reply.

In general, I understand you are making the point for a distributed
architecture, where processing and storage take place at the edge,
rather than a centralised one where all data is sent to a "server" and
processed there. Any architecture has pros and cons, and, while I do
agree that an exponential growth of connected devices will show the
limitations of a centralised architecture, what I am interested is to
see where the "boundaries" are. I will try to explain with an example. 

Problem: I want to install a camera system with facial recognition that
sends an alert in case of a known criminal is recognised.

Solution 1: I install N dummy cameras, I connect all of them with a
central server. The data stream is analised in the "central" location or
somewhere on the on the cloud where my services run.

Solution 2: I install N smart cameras, each of them with the
functionality of recognising a face in a set, and the camera will send
an "alert" signal if a face is found.

Both solutions work - on paper at least.

If I want to be very basic, I can see the two costs as follows:

Cost of Solution 1 is: (dummy camera cost) x N + connectivity to the
cloud + running the services on the cloud.  

Cost of Solution 2 is: (smart cameras cost) x N. + running some service
(mainly update pictures) on the cloud. 

It is clear that if the connectivity becomes a problem, it will become
very expensive (up to infinite if my requirements cannot be met) and
solution 1 is not feasible.  

Now, in real life the above equation cannot be just taken as-is: there's
the need to factor in the easiness of software upgrade in Solution 1
rather than 2, the fact that images need to be upgraded, which means
sent to cameras from time to time, that in the solution 2 there's the
need to send a signal if a face is recognised - which means, the cameras
must be connected at all times and there is therefore a connectivity
cost, albeit small, and so on ... but the idea is that if the
connectivity cost is bigger than the delta between a smart and a dummy
camera, then the distributed solution is better.

What it may be interesting is to study the characteristics of the two
architectures (or more, if you consider for instance computation at the
real edge - on the device - or in the local intranet) and look all the
different parameters that have an influence, to highlight which paradigm
should be chosen given a specific set of requirements. This for me would
fulfill "

"[...]the benefits and challenges of Edge computing mainly focused on IoT data.  The purpose of this document is to bring up the issues of Edge computing for IoT services in IETF/IRTF."

as you wrote. 

As well, please find some comments inline.

On 03. 04. 19 16:00, 홍용근 wrote:
> With respect to all your comments on the lack of the evidence data or
> references, we will clarify them in the next revision.
>
> *From:*Alessandro Bassi [mailto:[email-masked]]
> *Sent:* Tuesday, April 2, 2019 7:44 PM
> *To:* 홍용근; [email-masked]
> *Subject:* Comments on draft-hong-iot-edge-computing-02
>
>  
>
> Dear authors
>
Well, I'm sorry to insist, but if you say "around 50% of data is stored
close to the data producer", I would expect a scientific proof of this.
I'm not questioning the value - it could be perfectly valid. Indeed, it
can be common sense. But "common sense" made the people think for
centuries that the earth was flat, if you know what I mean ... so, in
general, I would refrain in indicating values if not supported by a
scientific study.  

>  
>
> 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.
>
> [Hong] IoT could include sensors, devices, and actuators.  We tried to
> provide very general concept of IoT since there are dozens of
> definitions as you said.
>
In my view, to be very generic, IoT MUST include a physical entity, a
digital entity (representation of the physical one, we can call it a
"digital twin"), a way to link the physical and digital world (through
devices, which can be sensors or actuators), and the possibility of
exchanging information. One rather poetic and extremely generic
definition I've heard for IoT is "where atoms and bits meet". The
definition you provide is

"the concept of IoT has been that things connected to the Internet can send and receive information collected by sensors without human intervention, where things are various embedded systems such as home appliances, mobile equipment, wearable
   devices"

I hope we can agree that this is not very generic ...

>
> 3.3
>
> "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?
>
> [Hong] Don’t you agree with it? Or are you asking the source as well?
> We will clarify this as well in the next revision.
>
It does not matter if I agree or not. "we will reach the post-Cloud era"
is a statement. If it's your statement, just say it.

> [Hong] Do you think that today's Cloud based service can satisfy any
> IoT applications which even requires very short response times and
> privacy? Or asking a source again? We don’t catch what you are asking.
>
>  
>
You cite three cases.

- very short response time: with the advent of 5G technologies that
_supposedly_ have a very short latency time, the response time should
not be an issue (or at least this is what the 5G narrative says). If you
disagree, please say why.

- personal data: it may be easier for an attacker to hack a device in
the wild rather than a well-protected computing center that is hosting a
cloud service. If a device is not able to encrypt messages in transit,
it will likely not be able to sustain an attack from a hacker.

- vast amount of data: if a device generates a large amount of data,
storing on-device will require that the device has a large amount of
storage, which may be expensive.

thanks! best,

--alex

---

From: Yong-Geun Hong <[email-masked]>
Date: Fri, 5 Apr 2019 11:30:21 +0900

Dear Alex.

Thanks again for your valuable comments. I appreciate your comments and it
will very helpful to research IoT and IoT Edge Computing.
The proposed two solutions to solve the problems is also very familiar to
me. When we implemented an IoT system, we also followed two different
approaches and each approach has pros and cons. What I learned from this
implementation and experiment is that it is impossible to tackle every
requirements of IoT services with only one approach. Some IoT services are
more suitable with solution 1 and some other IoT services are more suitable
with solution 2.

I also agree what you said, "What it may be interesting is to study the
characteristics of the two architectures (or more, if you consider for
instance computation at the real edge - on the device - or in the local
intranet) and look all the different parameters that have an influence, to
highlight which paradigm should be chosen given a specific set of
requirements. This for me would fulfill ". If we answer your questions,
then we would be happy. But, as you know, this is very challenge.

With all of your comments, we will try to solve comments with a next
revision.
One of my concern is that this draft is an internet draft targeting to a
Standard, not to a technical paper. This means that we can not include all
of issues and it is needed to have a specific issue and scope to solve a
problem. Even though, your comments are very valuable to progress the draft.

Best regards.

Yong-Geun.

On Thu, Apr 4, 2019 at 10:51 PM Alessandro Bassi <
[email-masked]> wrote:

> architecture, where processing and storage take place at the edge, rather
> than a centralised one where all data is sent to a "server" and processed
> there. Any architecture has pros and cons, and, while I do agree that an
> exponential growth of connected devices will show the limitations of a
> centralised architecture, what I am interested is to see where the
> "boundaries" are. I will try to explain with an example.
>
> Solution 2: I install N smart cameras, each of them with the functionality
> of recognising a face in a set, and the camera will send an "alert" signal
> if a face is found.
>
> Cost of Solution 1 is: (dummy camera cost) x N + connectivity to the cloud
> + running the services on the cloud.
>
> the need to factor in the easiness of software upgrade in Solution 1 rather
> than 2, the fact that images need to be upgraded, which means sent to
> cameras from time to time, that in the solution 2 there's the need to send
> a signal if a face is recognised - which means, the cameras must be
> connected at all times and there is therefore a connectivity cost, albeit
> small, and so on ... but the idea is that if the connectivity cost is
> bigger than the delta between a smart and a dummy camera, then the
> distributed solution is better.
>
> *From:* Alessandro Bassi [mailto:[email-masked]
> <[email-masked]>]
> close to the data producer", I would expect a scientific proof of this. I'm
> not questioning the value - it could be perfectly valid. Indeed, it can be
> common sense. But "common sense" made the people think for centuries that
> the earth was flat, if you know what I mean ... so, in general, I would
> refrain in indicating values if not supported by a scientific study.
>
>
>
> 3.1
>
> it? As there are dozens of definitions for IoT, I would recommend maybe to
> pick one of the existing ones.
>
> provide very general concept of IoT since there are dozens of definitions
> as you said.
>
> exchanging information. One rather poetic and extremely generic definition
> I've heard for IoT is "where atoms and bits meet". The definition you
> provide is
>
> 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?
>
> [Hong] Don’t you agree with it? Or are you asking the source as well? We
> will clarify this as well in the next revision.
>
> [Hong] Do you think that today's Cloud based service can satisfy any IoT
> applications which even requires very short response times and privacy? Or
> asking a source again? We don’t catch what you are asking.
>
>
>
> You cite three cases.
>
> _supposedly_ have a very short latency time, the response time should not
> be an issue (or at least this is what the 5G narrative says). If you
> - personal data: it may be easier for an attacker to hack a device in the
> wild rather than a well-protected computing center that is hosting a cloud
> service. If a device is not able to encrypt messages in transit, it will
> likely not be able to sustain an attack from a hacker.
>
> _______________________________________________
> T2TRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/t2trg
>