kumoh national institute of technology
Networked Systems Lab.

Review Comment

NSL > Education> Review Comment
Hong-Keu ETFA 2017
By :
Date : 2017-06-19
Views : 116

Review 4
Overall evaluation: -1


This works proposes an approach to migrate virtualized systems running on an overloaded computing host to other hosts of a naval combat system.
The authors propose the use of live migration based on policies related to resource usage on both the virtual machines and the physical computers.
For that, the resource usage is classified under 6 types that, in turn, is used to select the most suitable match between the resources demand of the VM and the offered resources of the physical computer.

Although the idea seems interesting, unfortunately, in this reviewer opinion, the text is a bit confusing on the novelty and the main expected contributions of this work.

In order to improve this short paper, it is important to make the text more clear and explicit on the following issues.

1. It is important to describe clearly the research problem and the main motivation of this work.
What is the difference of load balancing in a regular (and civil) cluster in comparison with a cluster of a naval combat system?
Are there different and specialized computers and hardware or are they COTS components?
It would be worth to describe the usage scenarios, especially the engagement and non-engagement situations, in order to highlight why is the load balancing a critical issue in the target application.

2. The description on the proposed selection schema is confusing.
What is T policy? What is R policy?
The author must be more explicit that T policy is related to the A-F types presented in Fig 1 and R policy is related with the raking created once the VMs and host are classified in the A-F types.
Moreover, the description of these policies and how they are applied need to be clarified.
Authors presented some formulas in section II.A, but the meaning of each formula and their terms is confusing.
What do scl*vm terms mean? Do they mean the maximum capacity of VM or host resources?
What do *vm terms mean? Do they mean the available resources or the resources usage?
How are these terms calculated? Does the system (VM or host) provide such info?
Why aren't there types in which two or three resources have the same amount (e.g. C and M are equal, or C, M and N are equal)?
What are the criteria (or thresholds) to define the three value categories H, M and L?
What does it mean the "similarity" and "symmetry" relations? Please be more explicit and detailed how have these relationships been defined.
In the first example, the authors claim that the VM are classified as a F type, and thus, the target host must be classified as a A type.
Why do not migrate such a VM to a B type host (the overloaded resource is CPU after all)?
It seems that the propose approach relates different kinds of resources (e.g. CPU and Network) in order to make the decision on the target host for migration.
CPU and networking (or CPU and memory, or memory and networking) are resources of distinct nature and they server to different purposes.
How can they be combined in a coherent decision making process?
Isn't processing (CPU) more important?
Thus, it is a bit confusing whether using such a combination will effectly provide the expected gains.
Authors are requested to detail and explain better why this is important and why it should be used rather than focusing on optimizing only one resource usage.

3. There is no discussion on partial and preliminary results.
It would facilitate the reader understanding whether the preliminary results and their analysis can be presented.

---------------------------------------------------------------------------------------------------------

Review 2
Overall evaluation: -2


This paper proposes some heuristics for migration of VMs to hosts for load balancing, when the load on multiple separate resource types is considered. The context is that of a a naval warship computer system, but it could be any system where VM migrations need to be managed both on the basis of current load and historical patterns of bursty high loads. The same heuristic is applied both for migration based on current load and for migration (called "pre-migration") based on expected future resource use surge (as reflected in the past history of that VM). What is the heuristic?

VMs and hosts are classified as being heavy, medium or light, in terms of usage, for each of the three resources and based on these combinations (e.g., HML, LLH, ...) they are categorised in types. The migration tries to match VMs and hosts of "matching" (complementary) types (called "symmetric" in the text). This is analogous to Tetris. (The comparison is meant illustratively and not disrespectfully.) The VMs and hosts of each type are also ranked in terms of absolute resource usage, so if one cannot match by type, the match is by rank.

I think that it is an intuitive and meaningful heuristic, that is likely to work well. However, it is a bit too obvious, in my opinion. Moreover, the authors are somewhat vague in their descriptions (read detailed comments).


Detailed comments, in order of appearance (including minor ones):

Irregular -> irregular

risk of service provision -> risk in service provision

many existing studies proposes -> many existing studies propose

the host which have -> the host which has

There is a reference [4] in the text but at the end of the paper, the reference list has only 3 references!

However, the probability -> However, if the probability


"In addition, first, these papers do not include ...." You do not cite any papers to

justify this statement.

There are many host and VM -> There are many hosts and VMs

so each host and VM to exhibit -> so each host and VM tend to exhibit

all of resources -> all of the resources

of each nodes -> of each node

three resources information as ... -> information on three resources, namely ...

"Unlikely". I am not sure what you mean here.

The scale VM -> The scaled VM
//many instances in the text; also scale host -> scaled host etc

host resources value -> host resource values

it can compare easily -> we can compare easily

VMs can be defined six types -> six types of VMs can be defined

"Based on the scale value, we define the highest used resource as H, medium as M, and lowest as L."
You are not being clear enough. If you have many nodes (for example, 10), the most utilised one with respect to one resource type, will be "H" with respect to that resource. Similarly, "L" for the least uilised one. But what about the other 8, in-between? Are they all "M"? Or, if one of them is close enough in utilisation to the "H"-node is it also described as "H"? (Similarly for "L".) In the latter case, how do you define the thresholds?

The same type two virtual machines -> Two virtual machines of the same type

"high rank is given to the most resource consuming VM" This is not clear either. Most resource consuming according to which of the three resource types? All three summed?

"Likewise, if there is no host of the same type in the destination host selection process, the similar type host is selected as the destination host according to the rank." Probably you mean: "If there is no host of the same type in the destination host selection process, then the destination host is selected only according to the rank." Otherwise, it does not make sense.

with more small number of iteration -> with fewer iterations

more fast -> faster

"require performance for short period in engagement situation than the long period in

normal situation" -> "require more performance for a short period, in engagement

situations, than in the long period in normal situations"

not engagement situation -> non-engagement situation

if there is VM -> if there is a VM

... increasing. First, ... -> ... increasing, first, ...

---------------------------------------------------------------------------------------------------------

Review 3
Overall evaluation: -1


The paper proposes a way to define a policy to balance the load of real hosts in a network of virtual machines that work together in a simulation environment.

The topic of the paper is a bit tangential to RTNES but it would be acceptable if the paper were a bit better worked.

Some weak points:
There are many issues with the use of the English language.
There is no outline.
Reference [4] is mentioned but not included. ( Son et al. [4] presented an)
There is no description of any potential experimental setup for a performance evaluation of the proposed policies (though it is desired as future work).
The description of the problem is very synthetic and not really fully understandable.
When you say But many existing studies proposes an algorithm to select a virtual machine to be migrated by monitoring the CPU usage of the virtual machine., please include as references some of them.
When you say: In addition, first, these papers do not include network traffic considerations and load prediction algorithms,., please indicate which are the papers there mentioned.

As a good point I may say that the idea of how to make the balance looks promising.

---------------------------------------------------------------------------------------------------------

Review 1
Overall evaluation: -3


This paper lacks sufficient content. The space that is not utilized could have been used to explain in a more clear way the VM placement function. This contribution needs further explanations to evidence why this scheme is different from the myriad of contributions of the same kind. It seems that authors leave out too much information, and only 3 pages explain vaguely the placement of this contribution within the migration scheme. There is no sufficient discussion of any potential targeted result.
 
Ʒ ̺
     Alif - ETFA 2017
Ʒ  Hak-hui - ETFA2017