Session Initiation Protocol Proxy in a Role of a Quality of Service Control Application in Software-Defined Networks
Round 1
Reviewer 1 Report
In the abstract section, they must focus on the novelty of the proposed approach, and at the end of the abstract, they can add the numerical results. They don't have the rest of the paper at the end of the introduction. This paper has grammatical problems and needs revision. The references are not in the same format. The technology section is inadequately described. All charts must be explained completely, for example, Fig. 6. Types of encryption affect the response time and execution time of the network, and they have to describe the encryption as part of their method. In the comparison table, we need to have a numerical result between all related works and our proposed approach, using words such as "fast" or "slow" for the execution time is not suitable. This paper doesn’t have novelty, and it needs a major review.Author Response
Dear reviewer, thank you for your remarks which helped us to improve out paper. We appreciate the time that you have invested. Revisions relevant to your points have been highlighted with blue color.
Point 1: In the abstract section, they must focus on the novelty of the proposed approach, and at the end of the abstract, they can add the numerical results
Response 1: We have reformulated the end of the abstract. Unfortunately, we do not have numerical results, but we proved the efficiency of proposed approach.
Point 2: They don't have the rest of the paper at the end of the introduction.
Response 2: At the end of the Introductions, additional information had been added, making the key objectives clearer.
Point 3: This paper has grammatical problems and needs revision. The references are not in the same format.
Response 3: An extensive revision has been done in terms of both the language and formal aspects of the paper.
Point 4: The technology section is inadequately described. All charts must be explained completely, for example, Fig. 6.
Response 4: Entity labels in figure 2 have been added. Figures 6 and 7 have been described further in the text by a comparison.
Point 5: Types of encryption affect the response time and execution time of the network, and they have to describe the encryption as part of their method.
Response 5: Though it has been outlined in the paper, encryption was not used in the experiment. However, compared to some of the other methods relying on direct packet inspection, the proposed solution should prove to be more robust.
Point 6: In the comparison table, we need to have a numerical result between all related works and our proposed approach, using words such as "fast" or "slow" for the execution time is not suitable.
Response 6: In the last column, there have been added approximate units, giving a clearer idea of the range. The rest of the comparison table is mostly based on comparing some of the derived characteristics that are not directly related to the final performance, but they could be important when choosing the right implementation.
Author Response File: 
Author Response.docx
Reviewer 2 Report
The authors propose a QoS application for VoIP traffic, in an SDN network that relies on the SIP proxy to send flow identification data to the SDN controller.
The idea and the contributions are clearly presented. The solution is validated through a demonstrator.
Some remarks about the paper:
The solution is a basic one. It just prioritizes the SIP flows against the other flow in the network. It does not have admission control for the VoIP flows in case the number of SIP calls will exceed the capacity allocated for the prioritized flows. The results are just for a single VoIP flow.
One major drawback of the solution is that it assumes a modified SIP proxy, which must send data to the SDN Controller. What happens if the SIP server is located in another domain? Who will configure the server to connect to the SDN controller? Does the SDN controller accept to interact with external entities and take management decisions based on data from these external entities?
It is not clear how the equation on page 8 is used in the paper and what is its relevance. The results in Figures 6 and 7 seem to be obtained based on the simulation results, not based on the equation.
It would have been interesting to include in the paper more details on how queue management is performed from the SDN controller.
The queue management is done via Openflow or the queues are configured in advance using Traffic Control on the Linux Mininet machines?
- "which is be able" - should be reviewed. - page 2
-"Aside from the proposed functionalities and basic connection this topology illustrated in ..." - comma is missing after basic connection.
-In figure 2 it is not clear the entities between which the messages are exchanged.
"... an IP address and a port picked up the SIP dialog as described" - probably it should be "...an IP address and a port picked up by the SIP dialog as described"
Author Response
Response to Reviewer 2 Comments
Dear reviewer, thank you for your remarks which helped us to improve out paper. We appreciate the time that you have invested. Revisions relevant to your points have been highlighted with green color.
Point 1: One major drawback of the solution is that it assumes a modified SIP proxy, which must send data to the SDN Controller. What happens if the SIP server is located in another domain? Who will configure the server to connect to the SDN controller? Does the SDN controller accept to interact with external entities and take management decisions based on data from these external entities?
Response 1: The solution indeed presumes that SIP proxy lies in its domain. However, just as we scale up the network, we can scale up SIP infrastructure as well. It would be sufficient if the nearest SIP server would be in the same domain, or, alternatively, there are authentication methods that could be used - trusted certificates for example.
Point 2: It is not clear how the equation on page 8 is used in the paper and what is its relevance. The results in Figures 6 and 7 seem to be obtained based on the simulation results, not based on the equation.
Response 2: The delay graphs in Figures 6 and 7 are based on the equation; although, some of the values from the simulation serve as input variables.
Point 3: It would have been interesting to include in the paper more details on how queue management is performed from the SDN controller.
The queue management is done via Openflow or the queues are configured in advance using Traffic Control on the Linux Mininet machines?
Response 3: After the testbed had been built, all network configuration was done via SDN controller, which then acted according to the OpenFlow specification. Initial configuration was performed statically with curl, followed by dynamic configuration from SIP proxy, both via HTTP exchange.
More advanced queue management would be possible with a designated application on the side of the SDN controller, however, a simpler method was chosen to validate the solution.
Point 4:
- "which is be able" - should be reviewed. - page 2
-"Aside from the proposed functionalities and basic connection this topology illustrated in ..." - comma is missing after basic connection.
-In figure 2 it is not clear the entities between which the messages are exchanged.
"... an IP address and a port picked up the SIP dialog as described" - probably it should be "...an IP address and a port picked up by the SIP dialog as described"
Response 4: Minor changes you pointed out have been corrected, including the entity labels in figure 2.
Author Response File: Author Response.docx
Reviewer 3 Report
"Classification will be controlled by SIP signalization in the network and thus should not need to rely on the standard classifiers that would be, in some cases, found unreliable."
1. The authors should clarify in the last sentence, that their proposal is only for the SIP Environment. Because it is compared later in related work to Classifiers based on Machine Learning that do not only classify SIP-RTP traffic.
From the problem description, it is clear that the setup or testbed is for a point-to-point SIP session. However, in the proposal it is mentioned that it is Quality of Service and that this can be provided by the SIP server.
2. The concept of QoS vs "traffic prioritization" should be considered in the document.
3. Section 4.1. Clarify if the type of vocoder used in the RTP session and defined in the SDP is taken into account for the QoS configuration process. How is this provided to the controller? only communication nodes are configured to prioritize traffic flow in end-to-end communication. This is an incomplete QoS concept.
4. From the description above, the bandwidth used by the RTP session and the codec used, is this provided to the SDN controller? This is an important issue for link bandwidth management by the controller.
5. From the graphs of results shown in figures 4 and 5, it is recommended to change the scale used to kbps.
Author Response
Response to Reviewer 3 Comments
Dear reviewer, thank you for your remarks which helped us to improve out paper. We appreciate the time that you have invested. Revisions relevant to your points have been highlighted with yellow color.
Point 1: The authors should clarify in the last sentence, that their proposal is only for the SIP Environment. Because it is compared later in related work to Classifiers based on Machine Learning that do not only classify SIP-RTP traffic
Response 1: It has been clarified in the mentioned sentence, that the solution is focused on RTP classification by using SIP messages of respective SIP calls. Indeed, the solution is not intended to be a general purpose QoS application.
Point 2: The concept of QoS vs "traffic prioritization" should be considered in the document.
Response 2: Some claims have been made clearer in that matter. Certainly, though related, the terms are not synonymous.
Point 3: Section 4.1. Clarify if the type of vocoder used in the RTP session and defined in the SDP is taken into account for the QoS configuration process. How is this provided to the controller? only communication nodes are configured to prioritize traffic flow in end-to-end communication. This is an incomplete QoS concept.
Response 3: Unfortunately, queue bandwidth could not be configured dynamically in our setup. However, if someone intended to develop an SDN application with this functionality, codec information could be extracted in the exactly same manner as presented in our paper.
Point 4: From the description above, the bandwidth used by the RTP session and the codec used, is this provided to the SDN controller? This is an important issue for link bandwidth management by the controller.
Response 4: As mentioned in the previous response, the codec is not used and the bandwidth is configured statically, although it could be easily provided.
Point 5: From the graphs of results shown in figures 4 and 5, it is recommended to change the scale used to kbps.
Response 5: The scale has been changed to “[kbps]”.
Author Response File: Author Response.docx
Reviewer 4 Report
For the introduction part: The authors should give a clear formal definition of the problem. The authors should add an example to illustrate the problem definition.
The language needs to be proofread.
The paper has several typos. Authors need to proofread the paper to eliminate all of them. The word 'our' should not be used in a research paper as it is too informal. The pronoun 'we' is used too many times in the paper. Generally, 'we' is appropriate to discuss future work in the conclusion, but besides that, it should be used sparingly.
There are only about 22 references which are insufficient for a scientific paper.
There are many irrelevant references. Authors should remove them to keep those closely related to the paper's topic.
For the method, I wish the authors would have sued Docker; nevertheless, the experiments have been carried out on Linux OS. Statistical analysis should be carried out to demonstrate that the experimental results are significant. There is not enough discussion of the experimental results.
The experiment should be added to show that the proposed solution can be used in real applications.
The worst part is the conclusion:
There should not be any references in your conclusion, as an effective conclusion for a research paper reminds your readers of the strength and impact of your argument. Concluding statements can also help refocus the reader's attention on the most important points and supporting evidence of your arguments or position in your research.
The conclusion of a research paper is where you wrap up your ideas and leave the reader with a strong final impression. It has several key goals:
Restate the research problem addressed in the paper.
Summarize your overall arguments or findings.
Suggest the key takeaways from your paper.
Finally, novelty is unclear, and the authors need to better explain the context of this research, including why the research problem is important.
Author Response
Response to Reviewer 4 Comments
Dear reviewer, thank you for your remarks which helped us to improve out paper. We appreciate the time that you have invested. Revisions relevant to your points have been highlighted with red color.
Point 1: For the introduction part: The authors should give a clear formal definition of the problem. The authors should add an example to illustrate the problem definition.
Response 1: Final section of the Introduction has been revised and extended to give a clearer idea of the problem and paper’s content.
Point 2: The language needs to be proofread.
The paper has several typos. Authors need to proofread the paper to eliminate all of them. The word 'our' should not be used in a research paper as it is too informal. The pronoun 'we' is used too many times in the paper. Generally, 'we' is appropriate to discuss future work in the conclusion, but besides that, it should be used sparingly.
Response 2: An extensive proofreading has been made. To your advise, words “our” and the majority of “we” were eliminated and replaced with passive forms.
Point 3: There are only about 22 references which are insufficient for a scientific paper.
There are many irrelevant references. Authors should remove them to keep those closely related to the paper's topic.
Response 3: Some less relevant citations have been removed (especially from the conclusion) and some, hopefully, more relevant citations have been added. Although the total count of the citations remains the same, I hope that the overall citation quality has improved.
Point 4: For the method, I wish the authors would have sued Docker; nevertheless, the experiments have been carried out on Linux OS. Statistical analysis should be carried out to demonstrate that the experimental results are significant. There is not enough discussion of the experimental results.
The experiment should be added to show that the proposed solution can be used in real applications.
Response 4: Unfortunately, the performed experiment was intended for validation purposes and to highlight the key characteristics. If we were to measure it in terms of performance, a substantially differenet approach would have to be chosen. However, it is to be considered as a future work in this area of research.
Point 5: The worst part is the conclusion:
There should not be any references in your conclusion, as an effective conclusion for a research paper reminds your readers of the strength and impact of your argument. Concluding statements can also help refocus the reader's attention on the most important points and supporting evidence of your arguments or position in your research.
The conclusion of a research paper is where you wrap up your ideas and leave the reader with a strong final impression. It has several key goals:
Restate the research problem addressed in the paper.
Summarize your overall arguments or findings.
Suggest the key takeaways from your paper.
Response 5: References has been taken out of the conclusion. After that, it was revised to highlight the mentioned key points.
Author Response File: Author Response.docx
Round 2
Reviewer 2 Report
The solution works for this simple scenario. There are no comments regarding a complex scenario where multiple VoIP flows compete for the same resources. How does the solution deal with the calls in this case? How it will affect the delay, jitter, and call quality?
Author Response
Response to Reviewer 2 Comments
Dear reviewer, thank you for your remarks which helped us to improve out paper. We appreciate the time that you have invested.
Point 1: The solution works for this simple scenario. There are no comments regarding a complex scenario where multiple VoIP flows compete for the same resources. How does the solution deal with the calls in this case?
Response 1: The core of the solution, which focuses on the classification process, would not differ in such a scenario; although, depending on the performance requirements, there are many techniques that could be deployed in cooperation with the method presented. While the priority of VoIP flows is guaranteed, various optimalization algorithms that could utilize the information obtained from SIP may be deployed. For instance, VoIP calls may be prioritized based on their accumulated delay, as was attempted in [1].
Point 2: How it will affect the delay, jitter, and call quality?
Response 2: The presented solution and other taken measures clearly have a positive impact on these parameters. However, appropriate network design is just as important when considering higher traffic volumes.
[1] Olariu, C.; Zuber, M.; Thorpe, C. Delay-based priority queueing for VoIP over Software Defined Networks. In Proceedings of the 2017 IFIP/IEEE Symposium on Integrated Network and Service Management (IM), 2017, pp. 652–655. doi:10.23919/INM.2017.7987352.
Author Response File: Author Response.docx
Reviewer 3 Report
The authors are taking notes on the previus comments.
They contribute to the initial steps of a simple approach between SDN Controller and SIP API REST for the transport of VoIP applications. They clarify it in the conclusions section.
The proposed physical topology is simple to represent a typical wide area network for SDN/DiffServ implementation; In addition, the authors could contribute by delving deeper into the challenge in the field of VoIP-SIP QoS knowledge.
Author Response
Response to Reviewer 3 Comments
Dear reviewer, thank you for your remarks which helped us to improve out paper. We appreciate the time that you have invested.
Point 1: The authors are taking notes on the previus comments.
They contribute to the initial steps of a simple approach between SDN Controller and SIP API REST for the transport of VoIP applications. They clarify it in the conclusions section.
The proposed physical topology is simple to represent a typical wide area network for SDN/DiffServ implementation; In addition, the authors could contribute by delving deeper into the challenge in the field of VoIP-SIP QoS knowledge.
Response 1: As outlined in the paper, the presented solution could cooperate with other VoIP techniques. The information provided by SIP could be utilized by various optimalization algorithms or QoS tools, which could prove to be effective in larger networks with high traffic volumes. Certainly, it is a great suggestion for further research.
Author Response File: Author Response.docx
Reviewer 4 Report
The authors have satisfactorily addressed most of my concerns. In particular, the authors have increased the resolution of the figures. They have eradicated most of the errors in the paper.
They also have literature work whereas 16 references are not sufficient for a proper scientific paper.
The reviewer expects the author to do more deep literature scans and add more (about 10 or more) works to the reference list.
The novelty should be highlighted.
Author Response
Response to Reviewer 4 Comments
Dear reviewer, thank you for your remarks which helped us to improve out paper. We appreciate the time that you have invested.
Point 1: The authors have satisfactorily addressed most of my concerns. In particular, the authors have increased the resolution of the figures. They have eradicated most of the errors in the paper.
They also have literature work whereas 16 references are not sufficient for a proper scientific paper.
The reviewer expects the author to do more deep literature scans and add more (about 10 or more) works to the reference list.
Response 1: Several more language improvements have been made. As far as the literature goes, there are 26 references now. Supplementary text has been added.
Point 2: The novelty should be highlighted.
Response 2: The novelty of this research lies in its particular design. Its specifics and advantages over similar solutions have been highlighted.
Author Response File: Author Response.docx
Round 3
Reviewer 4 Report
The Authors have addressed all of my concerns.
