Evaluation of Differentiated Services Policies in Multihomed Networks Based on an Interface-Selection Mechanism
Round 1
Reviewer 1 Report
This paper studies various DiffServ policies and examines multiple aspects for each policy. The result shows that TSW3CM provides the best tradeoff between performance and cost.
I would like to thank the authors for the efforts in this field. However, I find the current version fairly hard to follow. There are too many (1) casually used or undefined terms. A typical example is "nodes". I don't find any clarification before it is firstly used in contributions. The introduction section really should clarify such vague and heavily overloaded words before using it. Another example is "interface". Please find my detailed comments for more cases. (2) statements that are too vague and not informative. For example, "A well-defined collection of building blocks placed in network nodes can be used to create a wide range of services". (3) minor grammar glitches. Although I acknowledge grammar issues shouldn't be treated as a major problem when judging a paper, the draft should still be reader friendly and grammar issues are not severe enough as blockers for reading. Because of these issues, the introduction and background section really failed to provide sufficient background and motivation for this work. I would highly recommend the authors to find a native speaker to rewrite/proofread the draft.
Another major concern is for the convincing level of evaluation. Given that the evaluation results are a major part of contribution, I would highly recommend the authors to clarify the experiment setup more. Currently I don't find sufficient clues that the simulation on synthetic data is generic enough to support the final conclusion.
Please also find my detailed per-section comments below:
Intro
- "which signals follow and depend individually on, to gain the required network resources to allocate quality of service for every route": I cannot quite parse this sentence. Do you mean "on which signals follow and depend individually on"? ie. the signals depend on qos arch to improve service quality. Or "whose signals follow .."?
- "Some problems stayed with scalability, which was the motivation .. certain established QoS standards": what do you mean by "stay with"? What are the "other problems" in terms of "some problems" here? Given that you're using "was", does that mean it is no longer the motivation now? What are "certain established QoS standards" and how are they relevant to PHB? I highly recommend breaking this sentence to several shorter ones instead of so many clauses.
- "an effective platform to deal with clients": this is too vague as an intro. What do you mean by "deal with"? What are "clients" (especially when you're using "users" consistently above)? Does that mean handling users' demands? Accountability? Reachability? Availability? etc. etc. This sentence said nothing but "ISPs can use DiffServ". This is not informative enough.
- "when nodes managed to switch between them according to their availability": what is a "node"? Why do nodes manage switches and have one switch in between? This word is not mentioned at all before this sentence. Do you mean end hosts? (But from figure 2, it seems that you're talking about something else. Please be more clear what "node" is here in intro.)
- The too long sentences are really not reader friendly.. eg. "The QoS mechanisms we discussed thoroughly are based on communication performance enhancement with the principle of multihoming and condition-awareness, according to the availability of resources, iinvestigating the possibility of combining these strategies within the communication network to guarantee the users receive the best end-to-end QoS." I'm confused what is the subject of "investigating" (plus a typo there), do you mean "The QoS mechanisms are investigating the possibility of ..."?? That doesn't sound correct. Or maybe "principle of investigating the possibility of"? Please consider controlling as many sentences below 2 lines as possible...
Background
- In section 2.1, it seems that handover and load balancing are exclusive. If the user is using multiple ISPs simultaneously, does he/she still need a handover? Also, at the end of 2.1, you mentioned "handoff", what's the difference with handover? Do you just use them casually and exchangeably?
- "DiffServ is a series of techniques that let ISPs offer diverse services to different kinds of clients and relevant traffic": what is "relevant traffic"? Is there any "irrelevant traffic" in some sense?
- "without requiring a per-flow state or hop-by-hop signaling": Does this contradict with PHB?
- "The SLS can include expected throughput, failure": How can failures be predicted? Failures are always random in prod networks and there's no way to "expect" failures.
- " including the use of IP Precedence bit settings in IP packets or source/destination addresses": I'm confused - do you mean (1) we can set a bit in src/dst address? (2) does "IP packets or source/destination addresses" imply the addr are not in the IP packets?
- "and they involve them so that they can meet the required quantitative performance": what are "they" and "them" referring to?
- "BNs must execute traffic conditioning functions": what are "traffic conditioning functions"? Are they the traffic classification mechanism introduced in the previous paragraph?
Evaluation
- In the simulation, what is the traffic pattern of the synthetic traffic and why is it representative to support the conclusion? Given that the experiment results are claimed as an important contribution, this part must be clarified.
- It would be more helpful to explain the policies used for comparison more, and possible explanation of the results (eg. why TSW3CM outperforms others). Otherwise, I'm not convinced that the results can support the conclusion, especially given the point I mentioned above.
nits:
Many minor grammar glitches... Below are several but I don't intend to provide an extensive list.
- "the DiffServ", "which aggregates the flows and allocates the appropriate resources": the word "the" is redundant
- "are challenging Internet networks with various users' demands": the word "networks" is redundant
- "the optimum route": optimal
- "we've configured": "we have", it is highly recommended to spell out words in scientific writing
- In fig 5, the y label has a redundant bracket
- Please consider putting the title of "Background" and "Reference" to a new page
Author Response
Thank you for the thorough review of our paper. Your review has been of great help for us to understand the weak points of this paper as well as to spot other minor mistakes, this resulted in an enhanced version of the original paper.
The following is our reply for the reviewer comments:
Intro
- "which signals follow and depend individually on, to gain the required network resources to allocate quality of service for every route": I cannot quite parse this sentence. Do you mean "on which signals follow and depend individually on"? ie. the signals depend on qos arch to improve service quality. Or "whose signals follow .."?
Answer: Sentence was clarified based on the reviewer’s comment, please refer to the updated manuscript.
- "Some problems stayed with scalability, which was the motivation .. certain established QoS standards": what do you mean by "stay with"? What are the "other problems" in terms of "some problems" here? Given that you're using "was", does that mean it is no longer the motivation now? What are "certain established QoS standards" and how are they relevant to PHB? I highly recommend breaking this sentence to several shorter ones instead of so many clauses.
Answer: Sentence was modified based on the reviewer’s comment, please refer to the updated manuscript.
- "an effective platform to deal with clients": this is too vague as an intro. What do you mean by "deal with"? What are "clients" (especially when you're using "users" consistently above)? Does that mean handling users' demands? Accountability? Reachability? Availability? etc. etc. This sentence said nothing but "ISPs can use DiffServ". This is not informative enough.
Answer: Sentence was updated based on the reviewer’s comment, please refer to the updated manuscript.
- "when nodes managed to switch between them according to their availability": what is a "node"? Why do nodes manage switches and have one switch in between? This word is not mentioned at all before this sentence. Do you mean end hosts? (But from figure 2, it seems that you're talking about something else. Please be more clear what "node" is here in intro.)
Answer: All were clarified based on the reviewer’s comment, please refer to the updated manuscript.
- The too long sentences are really not reader friendly.. eg. "The QoS mechanisms we discussed thoroughly are based on communication performance enhancement with the principle of multihoming and condition-awareness, according to the availability of resources, iinvestigating the possibility of combining these strategies within the communication network to guarantee the users receive the best end-to-end QoS." I'm confused what is the subject of "investigating" (plus a typo there), do you mean "The QoS mechanisms are investigating the possibility of ..."?? That doesn't sound correct. Or maybe "principle of investigating the possibility of"? Please consider controlling as many sentences below 2 lines as possible...
Answer: Sentence was clarified and broke down based on the reviewer’s comment, besides the reviewer’s question was answered within the response, please refer to the updated manuscript.
Background
- In section 2.1, it seems that handover and load balancing are exclusive. If the user is using multiple ISPs simultaneously, does he/she still need a handover? Also, at the end of 2.1, you mentioned "handoff", what's the difference with handover? Do you just use them casually and exchangeably?
Answer: The user still needs to move from one base station to another with a soft handover (connect to the next station before disconnecting from the left one). The reviewer’s questions were answered in the updated manuscript and the word "handoff was changed".
- "DiffServ is a series of techniques that let ISPs offer diverse services to different kinds of clients and relevant traffic": what is "relevant traffic"? Is there any "irrelevant traffic" in some sense?
Answer: The sentence was clarified based on the reviewer's concern, please refer to the updated manuscript.
- "without requiring a per-flow state or hop-by-hop signaling": Does this contradict with PHB?
- "The SLS can include expected throughput, failure": How can failures be predicted? Failures are always random in prod networks and there's no way to "expect" failures.
Answer: No, it all has the same principle to achieve the same objective, moreover, please refer to the updated manuscript.
- " including the use of IP Precedence bit settings in IP packets or source/destination addresses": I'm confused - do you mean (1) we can set a bit in src/dst address? (2) does "IP packets or source/destination addresses" imply the addr are not in the IP packets?
Answer: The paragraph was modified for more clarification, please refer to the updated manuscript.
- "and they involve them so that they can meet the required quantitative performance": what are "they" and "them" referring to?
Answer: The sentence was clarified based on the comment, please refer to the updated manuscript.
- "BNs must execute traffic conditioning functions": what are "traffic conditioning functions"? Are they the traffic classification mechanism introduced in the previous paragraph?
Answer: It is an alternative solution in the case of CNs functionality shortage. The paragraph was clarified, please refer to the updated manuscript.
Evaluation
- In the simulation, what is the traffic pattern of the synthetic traffic and why is it representative to support the conclusion? Given that the experiment results are claimed as an important contribution, this part must be clarified.
Answer: We are considering “Queue-IN and queue-OUT parameters” (as shown in Table 1) in this study. For the implementation parameters, please refer to our previous published work in [36] and [37] cited in the Implementation section.
- It would be more helpful to explain the policies used for comparison more, and possible explanation of the results (eg. why TSW3CM outperforms others). Otherwise, I'm not convinced that the results can support the conclusion, especially given the point I mentioned above.
Answer: We are considering “Queue-IN and queue-OUT parameters” (as shown in Table 1) in this study. For the implementation parameters, please refer to our previous published work in [36] and [37] cited in the Implementation section.
nits:
Many minor grammar glitches... Below are several but I don't intend to provide an extensive list.
- "the DiffServ", "which aggregates the flows and allocates the appropriate resources": the word "the" is redundant
Answer: The manuscript was entirely and extensively revised/proofread by a professional native English academician. Besides, the glitches mentioned in the reviewer's comment were all corrected.
- "are challenging Internet networks with various users' demands": the word "networks" is redundant
Answer: It was corrected, please refer to the updated manuscript.
- "the optimum route": optimal
Answer: It was changed, please refer to the updated manuscript.
- "we've configured": "we have", it is highly recommended to spell out words in scientific writing
Answer: The mistake was corrected, please refer to the updated manuscript.
- In fig 5, the y label has a redundant bracket
Answer: Done, fig 5 and also fig 6 were updated, please refer to the updated manuscript.
- Please consider putting the title of "Background" and "Reference" to a new page
Answer: Done, please refer to the updated manuscript.
Author Response File: 
Author Response.docx
Reviewer 2 Report
This paper approaches the problem of evaluating the differentiated services policies in Internet multi-homed networks based on interface selection mechanism.
The paper is generally well written and well organized. Results presented in section 5 support the theoretical background presented in the first part of the paper.
The paper can be published as is.
Author Response
#Reviewer 2 comment:
The paper is generally well written and well organized. Results presented in section 5 support the theoretical background presented in the first part of the paper.
The paper can be published as is.
Thank you for this positive comments.
Author Response File: Author Response.docx
Reviewer 3 Report
This article presents the evaluation of differentiated services policies in multi-homed networks based on interface selection mechanism. The basic analysis, schematic, and preliminary results are presented. Soeme essential concerns need to be addressed, which are listed as below:
(1) The novelty, significance, and technical contributions of the proposed method need to be highlighted.
(2) The quantitative comparison results should be provided.
(3) A comparison table is suggested to be presented.
(4) The mechanisms of each policy should be demonstrated more clearly.
(5) It needs to make it clear if the results presented are from real testing results or simulation results. If from testing, the scenario setup and considerations should be illustrated.
(6) The demonstrated schematics are too general and the specific contributions are hard to find in the current version. It suggested to highlight on the unique technical contributions.
Author Response
#Reviewer 3:
Thank you for the thorough review of our paper. Your review has been of great help for us to understand the weak points of this paper as well as to spot other minor mistakes, this resulted in an enhanced version of the original paper.
The following is our reply for the reviewer comments:
(1) The novelty, significance, and technical contributions of the proposed method need to be highlighted.
Answer: The manuscript has been revised to address the mentioned points besides it was entirely and extensively revised/proofread by a professional native English academician.
(2) The quantitative comparison results should be provided.
Answer: Please refer to Table 2 and Figures 4,5,6 & 7 as research quantitative comparison results
(3) A comparison table is suggested to be presented.
Answer: Please refer to Table 2
(4) The mechanisms of each policy should be demonstrated more clearly.
Answer: We are considering “Queue-IN and queue-OUT parameters” (as shown in Table 1) in this study. For the implementation parameters, please refer to our previous published work in [36] and [37] cited in the Implementation section.
(5) It needs to make it clear if the results presented are from real testing results or simulation results. If from testing, the scenario setup and considerations should be illustrated.
Answer: Simulation, using NS2
(6) The demonstrated schematics are too general and the specific contributions are hard to find in the current version. It suggested to highlight on the unique technical contributions.
Answer: Done, all were clarified, please refer to the updated manuscript.
Author Response File: Author Response.docx
Round 2
Reviewer 1 Report
Thanks for the response and the careful proofreading! The draft is indeed significantly improved and is in much better shape. I highly appreciate the efforts for improving it.
Now my concern mainly lies in experiments. In more details, why the current result is representative enough and how could future researchers reproduce it. Essentially, could you please elaborate on more about the setup, including traffic pattern and topology used for the experiments, and why you believe they are representative? I'm not quite convinced because in theory, I believe we can make up certain traffic that makes any policy to be the best. The same for topology.
BTW, in the response, please consider also providing your new text instead of asking reviewers to find the answer in the draft. That not only saves time and iteration for both of us but could also show the most accurate answers in your mind (since reviewers may find the answer in the wrong spot).
Several remaining points below:
- I'm not sure I understand the response to the previous comment "- "without requiring a per-flow state or hop-by-hop signaling": Does this contradict with PHB?" as "No, it all has the same principle to achieve the same objective, moreover, please refer to the updated manuscript." Given that PHB is per-hop behavior, how can it not require hop-by-hop signaling? I'm not sure where to find the answer in the updated manuscript.
- "We are considering “Queue-IN and queue-OUT parameters” (as shown in Table 1) in this study. For the implementation parameters, please refer to our previous published work in [36] and [37] cited in the Implementation section." I'm not asking for the networking parameters like the queue parameters, I'm asking for the incoming traffic pattern. For example, do you replay a prod traffic flow? Or do you inject traffic with poisson distribution?
nits:
- In section 2.1, at the end of page 3, there are 2 continuous "additionally", please consider replacing one with sth else.
Author Response
Dear esteemed reviewer,
Thank you indeed for the constructive concerns and valuable comments. Please find attached the detailed report, we hope you will kindly find it convincing.
Best regards,
Author Response File: 
Author Response.pdf
Reviewer 3 Report
This revised version can be accepted.
Author Response
Thank you for the valuable comments.
Round 3
Reviewer 1 Report
Thanks for the response and the improvement to the draft! The new figure added for the simulation setup does help a lot. The entire evaluation section makes much more sense after adding the new figure (and the corresponding text).
My major concerns are resolved and I only have several remaining minor concerns:
- The title of section 4 ("Implementation Environment") is a bit weird. I would suggest just calling it "Setup" and putting it into section 5. It is not a separate section but rather part of the evaluation.
- For your response, "Service categorization protocols on the Internet can be used and scaled for traffic streaming and packets marking", I'm still not quite certain why this sentence is relevant to my confusion about the contradiction between PHB and no requirement for hop-by-hop signaling. You mentioned that "DiffServ aggregates flows and allocates appropriate resources depending on the per-hop behavior (PHB) design" and "DiffServ IP improvements intended to qualify scalable service discrimination to Internet services with no required per-flow state or signaling in each hop" in the draft, and "It manages the traffic flows" in the response. I'm a bit confused if it really cares about flows or hops, or both. Do you mean "packets marking" is a technique recording per-hop behavior but DiffServ will only get the marking results at the end of each flow as the collection of all hops, so that it manages flows? I guess it might be helpful to clarify more what is "hop", what is "PHB", what do you mean by "manage flows" exactly.
Author Response
# Comments and Suggestions for Authors
Thanks for the response and the improvement to the draft! The new figure added for the simulation setup does help a lot. The entire evaluation section makes much more sense after adding the new figure (and the corresponding text).
My major concerns are resolved and I only have several remaining minor concerns:
- The title of section 4 ("Implementation Environment") is a bit weird. I would suggest just calling it "Setup" and putting it into section 5. It is not a separate section but rather part of the evaluation.
Answer: It was called "Setup" and moved (5.1) to section 5.
- For your response, "Service categorization protocols on the Internet can be used and scaled for traffic streaming and packets marking", I'm still not quite certain why this sentence is relevant to my confusion about the contradiction between PHB and no requirement for hop-by-hop signaling. You mentioned that "DiffServ aggregates flows and allocates appropriate resources depending on the per-hop behavior (PHB) design" and "DiffServ IP improvements intended to qualify scalable service discrimination to Internet services with no required per-flow state or signaling in each hop" in the draft, and "It manages the traffic flows" in the response. I'm a bit confused if it really cares about flows or hops, or both. Do you mean "packets marking" is a technique recording per-hop behavior but DiffServ will only get the marking results at the end of each flow as the collection of all hops, so that it manages flows? I guess it might be helpful to clarify more what is "hop", what is "PHB", what do you mean by "manage flows" exactly.
Answer:
- The sentence " with no required per-flow state or signaling in each hop" was removed to avoid confusion.
- The sentence " Its architecture specifies a scalable mechanism for classifying and managing network traffic" was added for more clarification.
- The paragraph "DiffServ aggregates flows and allocates appropriate resources depending on the per-hop behavior (PHB) design (as PHB governs the forwarding behavior assigned to a code point) and on certain established QoS standards (e.g., performance, availability, scalability, and serviceability). DiffServ is managing flow based on the marking results received from each node. Hence PHB (i.e., the forwarding behavior assigned to a DSCP) plays an important role in decision-making for the entire process. It defines the policy and priority (the forwarding precedence) applied to a packet when traversing a hop (e.g., routers) in DiffServ domain, and provides a specified amount of network resources to the marked packet in relation to other traffic on the Diffserv-aware system" was updated for more clarification.
We hope it is clarified sufficiently and it crosses the point now.
Author Response File: Author Response.pdf
