Paper Discussion 11a: A Component Architecture for the Internet of Things

[ericwendt]

Hope you're all doing well. Please leave critiques here.

[AkinoriKahata]

Reviewer: Akinori Kahata
Review type: Comprehensive

1. The problem being solved.

• IoT application consists of many devices, such as a wide variety of sensors and actuators. Because these devices are not always provided by one company, we have to have common rules to make different companies’ devices collaboration. Also, many events happen asynchronously, then managing events is essential for maintaining performances of IoT application, and secure all systems.

2. The main contributions.

• The authors suggested the method using accessor as the interface of many applications like web form on the internet. They also introduced the Discrete Event (DE) management method with timestamps and asynchronously atomic callback (AAC). Besides, they explained the Security Swarm Toolkit (SST), which provides reasonable authentication and authorization systems with Auth instead of the general PKI system.

3. Questions.

• How to prioritize each Discrete Event? I feel that DE systems have a good strategy for time consistency, but I think that a priority of each IoT application is different, then systems have to manage the priority.
• The heavy computation power that PKI systems need is always a problem, then SST is a reasonable solution. I cannot understand how SST systems make the root of the trust of authentication and authorization.
• This paper provides much information, but there are not so many quantitative evaluation results. I want to know the advantage of suggested systems. For example, in terms of the size of scaling, computational power, or latency of IoT application.

[searri]

Reviewer: Rick Sear
Review Type: Comprehension

Problem being solved

With the huge diversity of IoT devices that exist, it's unrealistic that all will conform to some unifying standard for secure communications between them, the cloud, and users.

Important contributions

The paper introduces the "accessor" framework, which means that IoT devices communicate with each other through hosted proxies. This means they won't have to conform to some standard. The paper also introduces the AAC concurrency model to synchronize all these services.

Questions

• I'm curious about how the model in this paper was received. Did people embrace the idea of proxies for IoT devices? Or is this just another "academic curiosity"?
• I still am not sure I understand AAC -- this has been mentioned in a couple papers now (as well is this Web Worker "not-a-thread but threadlike" thing), so if you have a chance to explain that, that'd be great.

[zacharied]

Reviewer: Zach Day
Review type: Comprehension

Problem being solved

As the landscape of IoT devices grows and, more importantly, evolves, maintaining standards in how they communicate with each other becomes more important. While the standard methods of inter-device communication such as Bluetooth and Wi-Fi work to establish basic communication between devices, more structure is needed to ensure consistent and simple communication as more new IoT devices are developed.

Important contributions

The paper introduces a "discrete event"-based communication architecture for Things to talk to each other. The core idea of this architecture is to separate the functionality of a device from its internals to create a vendor-independent internet of Things.

Questions

• Figure 2 shows the Mutable component outputting to to the ConstructUI component. One of the outputs of Mutable is the schema of (presumably) its own data. How is that useful to ConstructUI? If a developer was making a script that generates a UI from JSON data, wouldn't it have to know the schema in advance to be able to derive anything from the data?

• The concept of output ports of accessors producing what the paper essentially describes as "webpages, but for devices" seems like it has use outside of IoT space; for example, I could see an advancement on the typical server-sends-HTML model into a data-driven approach where the browser handles the design of the page. Have the authors considered applying this idea, or their DE-driven architecture as a whole, outside of IoT?

[grahamschock]

Reviewer Graham Schock
Review Type Critical

Problem Being Solved
There is more and more demand for devices to turn into smart devices. One way to make these devices smart is to give them access to a network and the ability for them to give and receive data from other devices. However, opening these devices to the network releases a pandora’s box of issues. There are a wide variety of communication issues that occur when these devices communicate.

Contributions
In order to support better communication between devices on the Internet of Things, the paper proposes a design model called “accessors”. To me this idea tries to mimic the human to human internet where in this case a device creates a website for other devices to interact with. The paper goes on to describe a model for handling these network interactions through a model called “asynchronous atomic callbacks” which describe atomic server side protocols where an AAC function call waits to start when all other threads/functions have finished executing.

Questions

1. In the first section, notably figure 2 we see a control diagram for an augmented reality application. Would an internet of things device be able to support this level of complex computing? For example, it is hard to imagine goggles would have the computing power or the battery power to sustainably carry out these operations.
2. In the section that details coordination between these devices on the network it says unexpected non determinism is a problem. What does that mean? What is non determinism? How does it affect the system?
3. The paper details functional programming especially in the atomic call backs section. Does using functional programming make it harder to develop as there is a steeper learning curve? Are there things we can not do because we need to use functional programming concepts?

Critiques

1. Functional programming and lock-less algorithms in the atomic callback section seem intriguing. I wish there was more of an explanation about what these algorithms look like and more of a discussion on the drawbacks etc.
2. I think there needs to be more detail about the privacy section. Why does moving computation mobily enhance privacy, besides big companies being evil?
3. I wish there was some experimental data to the paper. This would show if something like this is actually possible and would do a good job in showing the overheads discussed in the paper

[lrshpak]

Reviewer: Lily Shpak
Review Type: Critical

Problem Being Solved

The authors of this paper design accessors to facilitate the communication between a Thing or service to another Thing or service. They think there is a need to provide these accessors because there is a difference between how a device communicates with a human versus how it communicates with another device.

Main Contribution

The authors designed CapeCode which is a design tool to build accessors. They think that this will allow people to easily build accessors to act as proxies between devices.

Questions

1. Why are accessors better for device to device communication than what is already in place?
2. Does the accessor add another layer of unneeded complexity?
3. Will adding an accessor slow down the communication between devices?

Critiques

1. I like how they immediately talk about their contributions, CapeCode.
2. Graphics are extremely helpful for understanding the flows of the system.

[reesealanj]

Reviewer: Reese Jones
Review Type: Comprehension

Problem Being Solved:
As the domain of Internet of Things devices expands and increasingly becomes more complex in nature, there exist issues with extending open network connections to these devices. There are a multitude of issues with just opening Wifi and Bluetooth connections to all of these IoT devices, and there is a very unrealistic possibility all of these devices abide by best security practices.

Main Contributions:
The main contribution is the authors presented a framework of connection called the "accessor" framework whereby different IoT devices connect to one another using proxies. This system can be thought of as it has each device create its own interface where other devices can connect to. They also discuss AAC for handling these network interactions.

Questions:

1. What does the paper mean when they say "unexpected non determinism"? Does that refer to a situation like a many-to-many connection where one starting point have no clear endpoint (and even if this is the case that doesn't make sense in my reading of the paper).
2. What exactly is the cost associated with converting essentially an entire ecosystem of devices to this "accessor" model, and is it even feasible?
3. Does including this accessor layer create a prohibitive latency for computation-intensive devices? The paper does not specify.

[Others]

Reviewer: Gregor Peach

Review Type: Comprehension

Problem Being Solved:

In IoT systems and solutions, there tend to be complex webs of components all with complex requirements. Further complicating the matter, real world physical sensors and actuators are at play, and must be dealt with carefully.

Main Contributions:

This paper proposes what is essentially the actor model onto IoT. Basically by modeling the different components of the system as actors, they can make guarantees about how the system interacts over message passing mechanisms. Then on top of that they layer an Asynchronous Atomic Callback (AAC) mechanism, that helps the actors coordinate more efficiently. They then argue this is a good model for programming the IoT.

Questions:

1. AAC mechanisms are notoriously hard to use, being replaced by futures in almost every modern usecase (outside of C). How do they plan to deal with this ergonomically?
2. They talk a lot about security, but don't really mention performace/real-time stuff. How would this work in a hard or soft real-time context?
3. I was a little confused whether or not they extended this system beyond one "device" or not. How would they handle cross device communication?

[tuhinadasgupta]

Reviewer: Tuhina Dasgupta
Review Type: Comprehension

Problem:
As there is much diversity in IoT devices, a method of standardized communication between users, devices, and the Internet has yet to exist. There is a desire for a secure way to communicate between these 3 endpoints and this paper designs a tool to do so.

Contributions:
The paper introduces the accessor framework, used in their own design called CapeCode, which means that IoT devices communicate with each other through hosted proxies, so there's no need for a standardized method of communication. They also introduced the Discrete Event management method containing timestamps and asynchronously atomic callback. Additionally, they explained the Security Swarm Toolkit, which provides reasonable authentication and authorization systems with Auth.

Questions:

1. Has the idea of proxies been tested within the real world? Or is this more of an experimentation for academics/academic curiosity paper?
2. What is the overhead of adding proxies? Does it make them more or less feasible?

[samfrey99]

Reviewer: Sam Frey
Review Type: Comprehension

Problem:
Interacting with the IoT is a fundamentally different way of interacting with the internet. Instead of directly accessing hosted webpages or cloud applications, we interact with IoT devices which then access the internet for us. This poses significant security risks on open networks. Providing a unified framework for IoT device interaction could greatly simplify security and expansion of the IoT.

Contributions:
The authors propose an IoT framework where devices interact with accessors at the directive of a user. Each accessor acts as a webpage designed specifically for interaction with a device.

Questions:

• Wow, this was really in the weeds for me. Is AAC used here just to ensure that there's a time stamp on every event?
• The paper says that a properly written AAC implementation doesn't use locks and cannot deadlock, but if their implementation requires all actions to be atomic, isn't there now a far greater chance of live lock under heavy load?
• The authors address their security concerns by deploying their Secure Swarm Toolkit on edge computing devices. We've discussed at length how poorly defined edge computing is at this time, so is implementing security here really the best idea?

[ericwendt]

@AkinoriKahata, Akinori Kahata, Comprehensive - Aki brings up many of the core components of this architecture such as Asynchronous callbacks and DE. He also asks the question of priority, which is tip-toed around in the paper.
@searri, Rick Sear, Comprehensive - Rick questions about AACs and their usefulness, as well as how the paper was received by the academic community.
@zacharied, Zach Day, Comprehensive - Zach talks about DE and the structure of the system. He also makes mention of the GUI processor having to know the data schema beforehand.
@grahamschock, Graham Schock, Critical - Graham brings up the functional programming aspects of the system, as well as the non-deterministic nature. I also find it interesting that he inquires about the HUD example used in the paper.
@lrshpak, Lily Shpak, Critical - Lily brings up fantastic observations about the effectiveness of this architecture, such as the speed limitations, usefulness of development, etc.
@reesealanj, Reese Jones, Comprehension - Reese also brings up concerns dealing with the effectiveness of the system such as speed and converting systems to this generalized model.
@Others, Gregor Peach, Comprehension - Gregor expresses concerns with the AAC model, which appears to be becoming outdated. He also questions the time complexities of real-world applications of the architecture.
@tuhinadasgupta, Tuhina Dasgupta, Comprehension - Tuhina questions about similar real-world examples.
@samfrey99, Sam Frey, Comprehension - Sam questions about the AAC and how is could prevent locks, as well as the effectiveness of edge computing for IoT devices using this framework.