76 lines
6.9 KiB
Markdown
76 lines
6.9 KiB
Markdown
type:: [[REVIEWS]]
|
|
tags:: #[[COMPUTE CONTINUUM]]
|
|
year:: 2023
|
|
venue:: [[JOT]]
|
|
full-title:: SimulateIoT towards the Cloud-to-Thing continuum paradigm for task scheduling assessments
|
|
date-start:: [[25-05-2023]] - 21:55
|
|
date-submitted:: [[13-06-2023]]
|
|
external-links::
|
|
status:: [[DONE]]
|
|
deadline-submission:: [[16-05-2023]]
|
|
file:: 
|
|
|
|
- [[Highlights]]
|
|
- ((647f64d4-f72c-40d8-bcb1-eb48fe898756))
|
|
- What do you mean?
|
|
- ((647f64f9-eaf0-43b0-acff-2a0cf2c7c9fc))
|
|
- -> proposed simulator
|
|
- ((6480352b-4a9e-4a09-9e56-952713e6db98))
|
|
- You need to make explicit the novelty of this paper with respect to previous papers from the authors about SimulateIoT
|
|
- ((64803a8f-03a6-4f91-a4a9-c1499ca459e6))
|
|
- Why do you say that?
|
|
- This is repeated many times in the section. It requires explanation.
|
|
- ((64803c6b-b153-4456-b7df-b38219206c5b))
|
|
- So, this can impact the trustworthiness :-)
|
|
- ((64803cbd-ce52-49ba-aaa7-a19990fdb8dc))
|
|
- What are them?
|
|
- ((64888589-7318-48ab-8159-167032dc703b))
|
|
- ((648885ec-87a7-42e1-b844-d2f55727005a))
|
|
- ((64803ddb-3a89-4f96-9e8e-5d6a6c7f33c3))
|
|
- Put these elements to the Legend otherwise it's confusing.
|
|
- ((64804108-1977-4b05-be71-27c9cafeb120))
|
|
- Not visible in Fig. 2
|
|
- Neither ((64888bd3-99f2-4bbe-8fa6-edb7a85a7299))
|
|
- So in general we can say that not all the elements described in the texts are visible in Fig. 2
|
|
- ((64888de2-ba77-4fd7-b15f-0ae75676edc7))
|
|
- This is confusing. A workflow, as shown in Fig. 3, is defined in terms of tasks represented in DAG. Thus, Task and workflow are not considered as synonms. It's a matter of terminology, but I suggest to improve it:
|
|
- ((64888f67-daaf-47ec-8ede-a20e8579dd8f))
|
|
- Even in FIg. 4 Task and Workflow are two different entities.
|
|
- ((6480474c-5f9b-4426-9661-7b3576c71f90))
|
|
- Why not having everything in one section?
|
|
- ((64804838-ed30-4849-a098-7a51df981bfb))
|
|
- Size of what?
|
|
- ((6480e2b5-58da-4cf5-a34b-95a0e61bb1e8))
|
|
- What's the target?
|
|
- ((6480e2ec-6f8b-4dee-87de-456ccdb9869e))
|
|
- Does not parse.
|
|
- ((6482f8e7-e5b0-48de-a41e-8e18bc36c213))
|
|
- It needs to be simplified. The text is not always clear.
|
|
- ((64830213-e06f-4ee8-8fd3-b414a1fb2ea5))
|
|
- What does it mean that the task is generated? from what?
|
|
- ((648334c7-8ec6-4e62-be49-0fab38b6de95))
|
|
- To be double checked, but the offload concept has not been defined.
|
|
- Section 4 seems to be a repetition of Section 3. I suggest to merge them.
|
|
- 
|
|
-
|
|
- ((648895b4-b153-476b-9506-928d675b2ac1))
|
|
- A motivation like this should be added early in the paper. Discuss such a scenario by showing clearly what can be done and what cannot with the ste of the art approaches. Otherwise the reader has to wait the case study section to grasp what are the critical aspects that are supported by the proposed approach.
|
|
- ((64889622-3847-4351-a92c-d5366aff6c1c)) IN FIG.
|
|
- 
|
|
-
|
|
- ((648896a5-7b5e-4812-bc7e-a58ff156a535))
|
|
- The deployment infrastructure is nto clear. Thus the phase that relies on model-to-text transformations is not clear. It is not clear what's the target runtime infrastructure. Only at section 7.4 docker is mentioned. It is necessary to explain this part much earlier in the paper.
|
|
- ((648897a2-020c-4402-ad68-e65073f838ba))
|
|
- Concerning the simulation analysis it is not clear how the user can actually specify and check the attributes of interests. Is it only the execution time the attribute of interest and that need to be checked within given thresholds? How to specify such tresholds?
|
|
- [[Comments]]
|
|
- The paper presents SimulateIoT, a model-based approach to simulate the execution of IoT systems to be deployed in the Cloud-to-edge continuum. The paper presents an extension of a previous paper from the authors that was missing the capability of simulating employed task-scheduling proposals. The proposed approach has been applied to simulate an IoT system in the steel industry for predictive maintenance of electric engines.
|
|
- The paper is about relevant and interesting topics. My main concerns are related to the presentation of the work, which is not effective in highlighting the strengths and limitations of the proposed approach. The reader has to read the very end of the work before grasping the benefit of the approach and understanding some technical details that are not presented earlier. In particular:
|
|
- The paper is in some places verbose and not focused. . Sections 3 and 4 contain repetitive content that could be merged. I suggest introducing a motivating example earlier in the paper to demonstrate the limitations of existing approaches and justify the need for your proposed solution.
|
|
- The terms "simulation" and "testing" are used interchangeably throughout the paper. It is crucial to provide clear definitions for these terms and explain their differentiation within the context of your work.
|
|
- The attributes that users can focus on during the simulation analysis are not well-defined. Is the execution time the only attribute of interest, or can additional attributes be assessed? Furthermore, it is unclear how users can specify the thresholds of interest. Providing clear guidelines and examples for attribute selection and threshold specification would enhance the clarity of your approach.
|
|
- The paper lacks clarity regarding the deployment infrastructure, particularly concerning the phase that relies on model-to-text transformations. It is necessary to explain the target runtime infrastructure earlier in the paper. While Docker is briefly mentioned in Section 7.4, it would greatly benefit the reader to have a comprehensive understanding of the deployment infrastructure from the beginning.
|
|
- The paper does not consider any existing approaches as potential baselines for comparison. To establish the superiority of your proposed approach, it is essential to convincingly demonstrate that other approaches are unsuitable for the cases of interest. In the related work section, you claim that existing approaches based on mathematical models may negatively impact the trustworthiness of the simulator. Please provide a detailed explanation to support this claim and clarify why mathematical models are not suitable for simulation purposes.
|
|
- The terminology used for tasks and workflows appears to be inconsistent, as shown in Figure 3. It is important to clarify that tasks and workflows are not synonymous, as workflows are defined in terms of tasks represented in a Directed Acyclic Graph (DAG). I recommend improving the terminology to eliminate confusion. Even in Figure 4, tasks and workflows are depicted as distinct entities, further highlighting the need for terminological clarity.
|
|
-
|
|
- Overall, I think this is an interesting paper. Addressing these concerns through a major revision will significantly strengthen the paper.
|
|
- |