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

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 <
alessandro@bassiconsulting.eu> wrote:

> 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:
>
> 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:alessandro@bassiconsulting.eu
> <alessandro@bassiconsulting.eu>]
> *Sent:* Tuesday, April 2, 2019 7:44 PM
> *To:* 홍용근; t2trg@irtf.org
> *Subject:* Comments on draft-hong-iot-edge-computing-02
>
>
>
> 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?
>
> [Hong] We think this is a common sense and it is easy to predict.
>
>
>
> 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.
>
>
>
> "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.
>
>
>
> 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
> _______________________________________________
> T2TRG mailing list
> T2TRG@irtf.org
> https://www.irtf.org/mailman/listinfo/t2trg
>