Recommendations for Using QPN Formalism for Preparation of Incoming Request Stream Generator in Modeled System

Round 1

Reviewer 1 Report

Dear Authors,
When starting to read your paper, I have the following concerns:

I would suggest to justify the statement "QPNs provide greater modelling power than Queueing Nets (QNs) and Petri Nets (PNs) models" (page 1, lines 27 & 28).
Having in mind authors' goal "to make this paper self-contained" (line 39) a formal definition of QPN is necessary, as well as clear identification of specific benefits over QNs and PNs.

In section 1, a CPN model was used as motivation. Two modeling strategies are presented in Fig. 2, and results on 1000 runs of the model are presented in Fig. 3. It seems authors are surprised by the differences observed and justifies that "Such behaviour is related to the internal operating principle of the simulator included in the CPN Tools package.". I would prefer to say that those results are expected to happen as they are associated with the modeling strategies used, and I would describe the "internal operating principle of the simulator" as "the exact execution semantics defined to CPN". So, the designer needs to produce the exact intended behavior (benefiting from the exact execution semantics defined for CPNs). In this sense, section 1 is interesting to read, but has no contribution to the paper.

I would suggest authors to clarify statements at lines 78 to 80 "QPNs can be seen as an extension of stochastic PNs. The main idea of QPNs is to add queueing and timing aspects to the net places. QPNs allow queues to be integrated into the places of a PN.". As stochastic PNs associate time dependencies to the firing of transitions, and QPNs deals with places, I don't understand how QPNs can be seen as an extension to SPNs. I would suggest to clarify.

In line 100, authors stated that "In this article, we present a new version of the SG model which is based on QPNs.". I would suggest to explicitly refer to other models of SG.

When reaching page 6, I found section 3. Testing in QPME Tool, where authors included sub-section 3.1. Mathematical Model of QPN, which if complemented by the presentation of the associated execution semantics can answer some of my previous concerns. However, I suggest to include it earlier than inside a section related with a tool.

Overall, I see no justification to include CPN in the title, as it was used only in the motivation.

Author Response

Dear reviewer,

Thank you very much for your review and valuable remarks. You may find our responses to your comments below. The changes are marked in red.

 

Question/Comment 1:

I would suggest to justify the statement "QPNs provide greater modelling power than Queueing Nets (QNs) and Petri Nets (PNs) models" (page 1, lines 27 & 28).

Answer 1:

We have tried to explain the advantages in subsection “QPNs” e.g.: “The main idea of QPNs is to add queueing and timing aspects to the net places.”.

We have added new corresponding text to the article:

We have used two types of formal models that have been exploited in the one model. Queueing Petri Nets have the advantages of Queuing Nets (e.g., the network efficiency and evaluation of the system performance) and Petri Nets (e.g., logical assessment of the system correctness).

 

Question/Comment 2:

Having in mind authors' goal "to make this paper self-contained" (line 39) a formal definition of QPN is necessary, as well as clear identification of specific benefits over QNs and PNs.

Answer 2:

A description of the formal definition (subsection “Mathematical Model of QPN”) was moved to section 2.

 

Question/Comment 3:

In section 1, a CPN model was used as motivation. Two modeling strategies are presented in Fig. 2, and results on 1000 runs of the model are presented in Fig. 3. It seems authors are surprised by the differences observed and justifies that "Such behaviour is related to the internal operating principle of the simulator included in the CPN Tools package.". I would prefer to say that those results are expected to happen as they are associated with the modelling strategies used, and I would describe the "internal operating principle of the simulator" as "the exact execution semantics defined to CPN". So, the designer needs to produce the exact intended behaviour (benefiting from the exact execution semantics defined for CPNs). In this sense, section 1 is interesting to read, but has no contribution to the paper.

Answer 3:

We have added the following text:

Such behaviour is related to the exact execution semantics defined by CPN. In the first model, the restriction in the transition guard is considered during the binding of the tokens to the variables, before the transition fires. Thus in approximately half of the cases, User1 and resource 1 are chosen, whereas resource 2 (for any user) is chosen in the other half. In the second model, the binding for firing the transition is randomly chosen without any restriction and after the transition fires, the resulting token with restricted results (User2, resource 1) is dropped if necessary.

 

Question/Comment 4:

I would suggest authors to clarify statements at lines 78 to 80 "QPNs can be seen as an extension of stochastic PNs. The main idea of QPNs is to add queueing and timing aspects to the net places. QPNs allow queues to be integrated into the places of a PN.". As stochastic PNs associate time dependencies to the firing of transitions, and QPNs deals with places, I don't understand how QPNs can be seen as an extension to SPNs. I would suggest to clarify.

Answer 4:

The QPN formalism also has a timed transition.

We added this information to the article:

The main idea of QPNs is to add queueing and timing aspects to the net places and timed transitions.

 

Question/Comment 5:

In line 100, authors stated that "In this article, we present a new version of the SG model which is based on QPNs.". I would suggest to explicitly refer to other models of SG.

Answer 5:

Additionally line 100 (currently line 123) has been modified to refer to SG model from Sec. 1.

The following text was added to section 0 (6 new references):

Usually some kind of workload generator is applied to analyse the behaviour of the modelled system. A survey of such generators for general-purpose web-based systems is presented in [14]. Specialized traffic models may be considered for different systems, e.g. for industrial networks [15] or streaming video data, both for input [16] and output stream [17]. In such models, an input stream generator is usually a part of the workload generator. Such an arrival stream generator produces a stream of random input data according to the expected distribution. Petri net models of the system typically are built based on predefined structures – patterns [18], [19], in such an approach a stream generator is one of the integral components.

 

Question/Comment 6:

When reaching page 6, I found section 3. Testing in QPME Tool, where authors included sub-section 3.1. Mathematical Model of QPN, which if complemented by the presentation of the associated execution semantics can answer some of my previous concerns. However, I suggest to include it earlier than inside a section related with a tool.

Answer 6:

Yes, this subsection presents a formal model of QPN.

We changed a place of this subsection, and now you can find it in section 2.

 

Question/Comment 7:

Overall, I see no justification to include CPN in the title, as it was used only in the motivation.

Answer 7:

Changed to:

Recommendations for Using QPN Formalism for Preparation of Incoming Request Stream Generator in Modelled System

 

Thank you once again.

Best regards,

Authors

Reviewer 2 Report

The manuscript discusses a method for generating a stream of incoming requests with specified properties. The authors compare the use of the  Colored Petri Nets (CPN) and Queueing Petri Nets (QPN) formalisms adapted for generating streams consisting of two types of requests and two types of resources allocated for them. The QPN-based model has been shown to be more suitable for generating streams with predefined properties.

The proposed model is quite simple; it may be valuable not from a scientific point of view, but rather from a practical point of view.

Comments

1. It is necessary to put your model in a broader context. The bibliography consists of works by a quite small number of authors. The short overview in the introduction consists only of papers dealing with Petri nets and their modifications. However, it is advisable to review other methods for generating input streams based on other mechanisms to compare your method with others and show its benefits and advantages.
2. Figure 6 needs to be explained in more detail. Why in Figure 6 all modes have four inputs and five outputs, while in Table 3 each mode has two inputs and one output?

Minor Comments

1. P. 6, line 143: It is much better to define the notation "MS" in the text, rather than give a footnote. Otherwise, a footnote reference is read as a power: "TR²". This discourages the reader.
2. P. 6, line 151 and p. 7, line 159: The use of the indices i, j in the notation p_i and w_j is incorrect. You have already used them when defining sets PL and TR – lines 136 and 137, respectively.
3. P. 7, line 167: “set of places PL = {Res, Stream}” – where is the place “Users”? It was written above that QU_1,2 are subsets of PL.
4. P. 7, line 178: notation “–/M/oo/IS_Users” is not defined.

Author Response

Dear reviewer,

Thank you very much for your review and comments. You may find our responses to your comments below. The changes are marked in red.

 

Question/Comment 1:

It is necessary to put your model in a broader context. The bibliography consists of works by a quite small number of authors. The short overview in the introduction consists only of papers dealing with Petri nets and their modifications. However, it is advisable to review other methods for generating input streams based on other mechanisms to compare your method with others and show its benefits and advantages.

Answer 1:

The following text was added to section 0 (6 new references):

Usually some kind of workload generator is applied to analyse the behaviour of the modelled system. A survey of such generators for general-purpose web-based systems is presented in [14]. Specialized traffic models may be considered for different systems, e.g. for industrial networks [15] or streaming video data, both for input [16] and output stream [17]. In such models, an input stream generator is usually a part of the workload generator. Such an arrival stream generator produces a stream of random input data according to the expected distribution. Petri net models of the system typically are built based on predefined structures – patterns [18], [19], in such an approach a stream generator is one of the integral components.

 

Question/Comment 2:

Figure 6 needs to be explained in more detail. Why in Figure 6 all modes have four inputs and five outputs, while in Table 3 each mode has two inputs and one output?

Answer 2:

As you can see in Figure 5 for QPN model connections (between the "Users" queueing place and "Generator" transition and between the "Res" place and the "Generator" transition) are realized round-trip (arrows in both directions).  The same situation is shown in Figure 1 for the CPN model.

In Figure 6 you can find a low level of the QPN model (incidence function). The connection between the "Generator" transition and the "Stream" place is only one direction. In Figure 6 we model the return tokens. In Table 3 we concentrate only on the "Stream" place and generate new tokens.

We added this information to the article:

In Table 3 we concentrate only on the Stream place and generated new tokens.

 

Question/Comment 3:

1. 6, line 143: It is much better to define the notation "MS" in the text, rather than give a footnote. Otherwise, a footnote reference is read as a power: "TR2". This discourages the reader.

Answer 3:

Changed.

 

Question/Comment 4:

1. 6, line 151 and p. 7, line 159: The use of the indices i, j in the notation pi and wj is incorrect. You have already used them when defining sets PL and TR – lines 136 and 137, respectively.

Answer 4:

Changed.

 

Question/Comment 5:

1. 7, line 167: “set of places PL = {Res, Stream}” – where is the place “Users”? It was written above that QU1,2 are subsets of PL.

Answer 5:

"Users" is a queueing place, and you can find it in line 179 (first version) "QU1 = {Users}".

 

 

Question/Comment 6:

1. 7, line 178: notation “–/M/oo/ISUsers” is not defined.

Answer 6:

You might have found some information in line 200 (first version) "The Users has an Infinite-Server queue with an initial population of request tokens.", but, you have right, this is not enough. This is notation borrowed from Queueing Theory.

We added:

The used queue is described by Kendall notation (A/B/K/L), where A denotes the probability distribution function specifying the interarrival time of tokens (- means different requests interarrival time), B is the probability distribution function of a service time (M means exponential (Markovian) distribution of requests service time), K determines the maximum number of requests that can arrive in a queue (in this case is oo) and L - scheduling strategy (in this case is Infinite-Server).

 

 

Thank you once again.

Best regards,

Authors

Round 2

Reviewer 1 Report

Revision provided by authors improves some aspects of the initial submission. However, in my humble opinion, some other aspects need to be revisited, as follows.

Authors introduced in the Abstract the following statement: "such as CPN Tools, based on the Coloured Petri Nets formalism,". I cannot see a justification to criticize CPN Tools in particular. Why CPN Tools?

Overall, I continue to see no point to include a discussion around results summarized in Figure 3, as they come directly from the execution semantics defined to CPNs. The authors argued that this is a problem in the formalism. 
Authors ended up stating "Therefore, we feel that a more flexible model should be created, presumably in a different formalism, to simplify future works".
In my humble opinion this is a problem in the modeling strategy, and cannot be used to justify the use of a different formalism.
In summary, I think that section 1 on CPN Model is misleading, can be removed/reformulated and motivation to the proposal needs to be found elsewhere.
Of course that authors may prefer to use QPNs, but the motivation/justification cannot be based on the discussion around Figures 2 and 3. I would suggest to comment/clarify on that.

In line 56, authors stated that "Unfortunately, such a model is too simple to be realistic." when referring to the CPN model presented at Figure 1.
However, when presenting their own proposal, it seems to me that the model presented at Figure 5 is similarly too simple to be realistic. Could you please comment on that?

Author Response

Dear Reviewer,

 

Revision provided by authors improves some aspects of the initial submission. However, in my humble opinion, some other aspects need to be revisited, as follows.

We are grateful again for your valuable remarks and comments. We agree with your point of view. Therefore, we have removed or changed questionable fragments.

Authors introduced in the Abstract the following statement: "such as CPN Tools, based on the Coloured Petri Nets formalism,". I cannot see a justification to criticize CPN Tools in particular. Why CPN Tools?

The sentence has been removed.

Overall, I continue to see no point to include a discussion around results summarized in Figure 3, as they come directly from the execution semantics defined to CPNs. The authors argued that this is a problem in the formalism. 
Authors ended up stating "Therefore, we feel that a more flexible model should be created, presumably in a different formalism, to simplify future works".
In my humble opinion this is a problem in the modeling strategy, and cannot be used to justify the use of a different formalism.
In summary, I think that section 1 on CPN Model is misleading, can be removed/reformulated and motivation to the proposal needs to be found elsewhere.
Of course that authors may prefer to use QPNs, but the motivation/justification cannot be based on the discussion around Figures 2 and 3. I would suggest to comment/clarify on that.

We have decided to remove Section 1. All successive references to this section have been removed, or changed to refer to [7]. The following text has been added at the end of “Related work” section to clarify the difference between this paper and previous, with CPN model of SG [7].

In [7] Coloured Petri Nets (CPNs) were used to model the SG. Two different ways to impose restrictions on mapping between users and resources were considered there, i.e. transition guards or arc expressions. In this paper, QPNs are used instead of CPNs. Appropriate mapping in the output stream is achieved by means of transition modes and firing weights.

 

In line 56, authors stated that "Unfortunately, such a model is too simple to be realistic." when referring to the CPN model presented at Figure 1.
However, when presenting their own proposal, it seems to me that the model presented at Figure 5 is similarly too simple to be realistic. Could you please comment on that?

This sentence referred to the model without restrictions, where each user can freely choose each resource, which is unrealistic case. Currently the section 1 with this sentence as well as Figure 1 is removed. We agree that the model from Figure 5 (currently Fig. 2) is simple, but transition modes and firing weights are used to impose the restrictions and achieve appropriate mapping in the output stream, as described in the paper. 

 

Thank you once again.

Best Regards,

Authors

Reviewer 2 Report

Dear authors, 

thank you for the comprehensive answers and the consideration of the comments.

Wish you luck

Author Response

Dear Reviewer,

Thank you once again.

Best Regards,

Authors

Round 3

Reviewer 1 Report

Authors provided adequate answers/corrections to my previous concerns.