Paper Discussion 12b: Decision-driven Execution: A Distributed Resource Management Paradigm for the Age of IoT

[hjaensch7]

Summary: @pcodes: Given how many components there are to this paper, it would have been nice to see a more comprehensive example that demonstrated all functionality. @samfrey: Even though the paper focuses on a higher-level change execution flow, the data offers proof of concept and got me excited about the idea. @Bushidocodes: Some decisions require historical context and baseline information to discover trends? How might this architecture support this sorts of queries?

[bushidocodes]

Reviewer: Sean McBride

Review Type: Comprehension Review

Problem Being Solved:

How can one design a resource scheduling and management model for a massively distributed network of sensors (i.e. smart-city, military sensors in city during counterinsurgency operations) based around the needs of decisions?

Main Contributions:

1. Introduces a new resource management model, decision-driven execution, which differs from traditional time-drive (periodic) and event-driven models by making scheduling decisions around the acquisition of data needed to make decisions. The result is something that feels like Prolog queries, but where resolution depends on predicates (labels) that are evaluated lazily from data objects. The scheduler thus seems to incorporate aspects of logic programming.
2. Discusses several existing scheduling policies and introduces a new algorithm based on optimally short-circuiting and pruning label resolution by evaluating labels in order of the short-circuit probability / unit cost.
3. Discusses a technique to store labels in a hierarchical namespace in order to minimize redundant information (i.e. pictures of something from different angles).
4. Implemented Athena, a distributed system POC for decision-driven execution, and evaluated several data retrieval protocols for a simulated smart city, demonstrating substantially higher query resolution in dynamic environments.

Questions:

1. This paper assumes that sensors have a request-response pull model, rather than the periodic push model. What implications does this have for sensor design? E.g. does this affect the ability of battery-powered things like Signpost to go into deep sleep?
2. Some decisions require historical context and baseline information to discover trends? How might this architecture support this sorts of queries?
3. Would this scheduler be able to co-exist with sensors also performing traditional event-driven or periodic work? How would an understanding of slack or system load impact the decision of which sources to use in resolving labels?
4. How would the paper's scheduling policy (sequentially evaluate labels in order of the short-circuit probability / unit cost) maintain freshness in complex queries?

[samfrey99]

Reviewer: Sam Frey Review Type: Critical

Problem Expansion of the IoT means vastly more sensors, and these sensors may not fit a definable control loop structure for sequential processing of their data. In addition, not all tasks will require data from every sensor in the system. Therefore, we need a way to access data from only the necessary sensors on an as-needed basis.

Contributions The authors propose a decision-driven execution model for IoT devices. Sensors are only accessed when their data is required for a decision in the system. This allows for a more efficient use of sensor data and prevents the system from getting bogged down interpreting sensor data it doesn't really need.

Questions

• Many IoT devices currently rely on sensors to trigger processing events (i.e. motion sensors). How do these fit into an execution model like this? The paper mentions it briefly, but I don't think they really provide an answer.
• In the discussion section of the paper, the authors mention the paradigm's ability to learn about its users and surroundings to form a better decision-making model. This scares me, especially because the authors don't mention anything about security in the paper. How is data like this protected?

Critiques

• The architecture example in section 2 meant I actually understood the architecture before reading about its implementation.
• I have never been so happy to read an evaluation section of a paper. The authors actually offer performance data for their idea. Even though the paper focuses on a higher-level change execution flow, the data offers proof of concept and got me excited about the idea.
• The authors conclude the paper saying that their model could support national security applications. This is a huge claim having not discussed security at all in the paper. I think that calling it an "ongoing research challenge" is too little on the subject.

[pcodes]

Reviewer Name: Pat Cody Review Type: Critical

Problem Being Solved

A traditional means of programming IoT devices leads to a time or event-based means of scheduling. This, however, assumes a static control loop, and will not scale as the number of IoT devices increases. A more flexible solution is required.

Main Contributions

This paper introduces the idea of "decision-based execution", where IoT sensors are accessed as needed in order to solve a particular question. The system includes a new scheduling algorithm, that takes into account the need for fresh data and minimizing the number of IoT sensors needed. To manage the expected large number of nodes, it proposes a hierarchial semantic naming convention.

Questions

• One problem we've discussed in class is the inability to trust sensor data. How is that factored in (is it?) to the scheduling algorithm?
• On a more practical note, how do they envision implementing the system to be fault tolerant in a physical sense? One suggested use-case is a natural disaster, which carries the implication that infrastructure will be destroyed. Maybe this is outside the scope of the paper, but do the authors have any ideas on how to prevent their needed infrastructure (networks, etc.) from going down in this type of scenario?
• How secure/private do the authors envision these sensors being when used in their system? Could I make a query that ends up using a camera attached to someone's house?

Critiques

• Given how many components there are to this paper, it would have been nice to see a more comprehensive example that demonstrated all functionality.
• Nice to see they acknowledged the lack of complete evaluation

[rachellkm]

Reviewer: Rachell Kim Review Type: Comprehension

Problem Being Solved:

Traditional control loops involve static loops that follow time-driven and event-driven scheduling models. This paper introduces a new model for scheduling and resource management potentially more suitable for applications supporting IoT systems.

Main Contributions:

The authors of this paper propose a new paradigm to better manage and acquire sensing data from distributed systems. This model follows decision-driven execution as opposed to traditional time and event-driven loops for the purposes of optimizing resource management in IoT systems and satisfying needs for information in an efficient manner.

Questions:

1. They mention the need for past contextual knowledge combined with current observations to improve the quality of solutions in physical models. What is the cost of keeping/integrating collected historical data with the proposed models of this paper?
2. The paper discusses real-time decision-driven scheduling in section 4, but I’m quite confused at how this works. Wouldn’t this only be relevant to a certain subset of systems where the real-time requirement is not always constant (i.e. no indefinite constant streaming of real-time data)? Or am I misunderstanding a few key ideas?