University of Notre Dame NetScale Laboratory

Open Source Documents: Review - End-Wise Admission Control

Info - Why am I doing this?

Acceptance Letter

Dear Ms. Yingxin Jiang:

Congratulations - your paper #1569193461 ('End-wise Admission Control Delegation for Effective End-To-End Quality of Service') for IWQoS? '09 has been accepted as a 5-page short paper to be presented at the workshop and published in the workshop proceedings. This year we received a large number of high-quality papers, and we are looking forward to having an exciting program.

The instructions for preparing and submitting the final manuscript will be sent to you shortly. The deadline for the final manuscript submission is May 11. This deadline is firm due to a tight schedule. Please make sure that one author is registered at the full rate before submission.

The workshop will be held in the historic, seaport city of Charleston SC at the Charleston Place Hotel on July 13-15. Information about Charleston and the hotel can be found at the following URL links.

http://www.charleston.com/ http://www.charlestonplace.com/

The reviews are below or can be found at http://edas.info/showPaper.php?m=1569193461.

Regards, Shigang Chen (TPC Co-chair) Srihari Nelakuditi (TPC Co-Chair)

Review 1 - Likely Accept (4)

=== Review 1 ===

* Familiarity: Rate your familiarity with the topic of the paper. Some knowledge (I am marginally aware of research work in this topic) (2)

* Recommendation: Your overall rating Likely accept (top 20% but not top 10%, significant contribution) (4)

* Contributions: What are the major issues addressed in the paper? Do you consider them important? Comment on the novelty, creativity, impact, and technical depth in the paper.

The authors advocate the use of an approach to ensuring e2e QoS? that does not require all nodes along the routing path to participate in a admission control procedure. Under the assumption that the network core is overprovisioned in comparison to edge domains, admission control should be performed by edge router of the peering edge domains based on the information exchange between edge nodes. Although the scalability issue will be a problem with a larger number of peering domains, the idea of incremental deployment of QoS? mechanism seems worth considering and discussing. It represents the approach of starting with a solution that may be far from ideal but offers some starting point for future improvements, which is a good approach in practice.

* Strengths: What are the major reasons to accept the paper?

The main strength and an interesting element of the proposed mechanism is its characteristics related to the possibility of initially partial and growing with time deployment. The authors provide careful justification for the approach taken and first of all for the assumptions that were made. The properties of the proposed scheme are carefully analyzed and supported by the simulation results even if in the limited range.

* Weaknesses: What are the major reasons NOT to accept the paper?

The scenarios presented in the paper are rather simple as it is needed to explain the principles of the new mechanism. However, it is necessary to consider its behavior in a more complex scenarios which are more likely to occur in reality. The E3AC? properties should be examined for more demanding cases. Scalability issue should be addressed. Otherwise the usefulness of the scheme will be limited to simple cases and its ability to grow will be limited too.

* Detailed Comments: Please provide detailed comments that will help the TPC assess the paper and help provide feedback to the authors.

The new scheme is nicely presented with the justification and all assumptions explained. The main problem seems to be the fact that the advertised ability to grow QoS? inward may be limited by the scalability issue as the number of peering domains grows. The work should be extended to examine scalability and E3AC? 's properties under more complex scenarios. The simulation study section or background section could containat least a brief description of the most relevant features of the schemes with which E3Ac? is compared.

Review 2 - Likely Accept (4)

=== Review 2 ===

* Familiarity: Rate your familiarity with the topic of the paper. Familiar (I am well aware of research work in this topic) (3)

* Recommendation: Your overall rating Likely accept (top 20% but not top 10%, significant contribution) (4)

* Contributions: What are the major issues addressed in the paper? Do you consider them important? Comment on the novelty, creativity, impact, and technical depth in the paper.

The authors present an inter-domain admission control scheme with a view to ultimately enabling the practical deployment of a true end-to- end quality of service across ISP domain boundaries. Through analysis and simulation they compare their scheme with some existing approaches and demonstrate how it provides an improvement, particularly in setup latency, of end-to-end QoS? . The paper has some novelty and sufficient technical depth but it is difficult to assess its likely impact without an implementation of the idea.

* Strengths: What are the major reasons to accept the paper?

In the introduction the authors demonstrate a good understanding of the practical problems associated with provisioning end-to-end QoS? across ISP domain boundaries. The problem is very well articulated and they also justify their use of assumptions regarding the network core, namely that the core path is stable and over-provisioned. They provide sufficient simulation results to justify the viability of their scheme stress that it is not a perfect solution but a method that can grow QoS? inwards from the edge.

* Weaknesses: What are the major reasons NOT to accept the paper?

The proposed scheme is really just a new flow admission scheme and as such only considers the bandwidth requirement of a new flow. True end- to-end QoS? must also consider delay and packet loss requirements for a flow and how admission of a new flow will affect the delay and loss characteristics of already existing flows in the network. Also, some results of a prototype implementation of the scheme would be useful. Overall though, the strengths of the paper outweigh the weaknesses.

* Detailed Comments: Please provide detailed comments that will help the TPC assess the paper and help provide feedback to the authors.

This is a well written paper addressing a real problem within the Internet industry today. I have two criticisms however. First, the authors only consider the bandwidth requirement of a new flow in the admission control scheme. A true end-to-end QoS? model, however, should also address delay and packet loss requirements of a flow and how it may affect similar requirements for existing flows if admitted. Second, while the simulation results are good, a prototype implementation in a small network would really validate the approach and give it more chance of industry acceptance. Other than that, it is a nice idea and well presented.

Review 3 - Likely Reject (2)

== Review 3 ===

* Familiarity: Rate your familiarity with the topic of the paper. Familiar (I am well aware of research work in this topic) (3)

* Recommendation: Your overall rating Likely Reject (top 50% but not in top 30%, needs more work) (2)

* Contributions: What are the major issues addressed in the paper? Do you consider them important? Comment on the novelty, creativity, impact, and technical depth in the paper.

The authors propose a scheme to perform admission control at large scales in an "end-wise" fashion, by allowing the distribution of admission control functions over multiple parties. This problem is an important one to address, and solving it could have impact. The paper had sufficient technical depth to address the posed problem.

In particular, in this paper, the authors have proposed E3AC? (End-wise End-to-End Admission Control) system. E3AC? is an inter-domain admission control scheme. One of the basic assumptions of this paper is that core providers are over-provisioned. Although the assumption is not unrealistic, the authors have also acknowledged that this assumption has high risk as well since service level agreements of end ISPs with the core providers impose some stability requirements on core performance. However, E3AC? ensures end to end QoS? through leveraging this over-provisioned nature of the core provides.

According to the authors, the paper has three contributions: E2E? admission control without E2E? negotiations, Incremental deployment, and Comprehensive simulation studies.

The authors have introduced two concepts namely intra-domain heartbeat and inter-domain heartbeat. Through the utilization of inter-domain heartbeat, E3AC? delegates the admission control to the edge which, according to the authors, improves the setup latency dramatically and removes most of the on-demand control overhead of QoS? . Besides describing the underlying E3AC? framework, the authors have evaluated the E3AC? performance via simulation.

* Strengths: What are the major reasons to accept the paper?

The paper was clearly organized and well-written. The problem posed is an important one to solve, and the authors present a clear formulation of the problem. In addition, the scheme appears to be incrementally deployable. Some of their underlying assumptions were backed up with references. While I am not clear on whether the authors were able to solve this problem, the idea of providing E2E? QoS? without E2E? negotiation is an interesting one.

* Weaknesses: What are the major reasons NOT to accept the paper?

Contributions over previous work were unclear. Some of the core claims put forth by the authors were unclear or possibly overclaiming. There appeared to be some more minor technical shortcomings as well. Also, the authors did not clearly inter-domain admission control from intra-domain admission control, nor did they modify their system in any substantial way from their previous work.

In addition, this approach only seems applicable for applications that have short-lived and highly mobile flows, the authors have acknowledged that their underlying has high risk since service level agreements of end ISPs with the core providers impose some stability requirements on core performance, Figure 8 shows the UDP loss rate under link failure. Here we see that almost 4 sec is needed to adjust the link failure. Is this time short enough for a short-lived and highly mobile flow?, and E3AC? doesn’t provide the best result all the time. For example, if we consider link utilization, figure 5 shows that both EAC and BB perform better than E3AC? . Moreover, Table I and Figure 10 show that EAC performs better that E3AC? .

* Detailed Comments: Please provide detailed comments that will help the TPC assess the paper and help provide feedback to the authors.

The authors propose an admission control system that performs endwise admission control at large scales. One of the basic assumptions is that core providers are overprovisioned (i.e., that core providers have sufficient capacity). The authors then propose "negotiation-free" QoS? , which targets the ability of creating connections without negotiating between hosts. This works by setting up a connection via the local edge router, assuming the core doesn’t have contention, and using an “interdomain heartbeat” to reach the other edge router. The interdomain heartbeat is used to determine the residual capacity of the remote side of the connection.

First, I didn't understand the claim of "E2E admission control without E2E? negotiations", when I first read this I was quite intrigued as it seems like a novel approach, and frankly, something that's impossible to do. After reading the paper further, I'm not understanding how the author's approach removes the need for E2E? negotiations, instead it seems to shift that functionality to heartbeats, and to run them between edge routers instead of directly to hosts. While the point that core networks may not need to participate in negotiations may be true, it seems like the authors were, instead of solving the problem, instead considering a particular kind of scenario where the problem does not occur, which doesn't seem like a contribution (in general, the core contributions of this paper were somewhat unclear).

Second, some of the assumptions were somewhat unclear. For example, it was assumed that core providers always would have spare capacity. While this may be true at certain times and in certain locations, what about times of load, or when traffic shifts due to link failures? This may cause the provider to violate SLAs. While the provider may overprovision, use of the author's proposed approach would require them to overprovision more than they do today, increasing costs, and these costs were not discussed.

Third, the proposed mechanisms seem similar to the author's previous work on intra-domain heartbeats. While the authors claim that inter-domain admission control has several additional challenges (increased delay, trust issues, oscillations over multiple paths), the authors only make a minor change to their design, and only address delay. They do this by modifying a formula to take delay into account, however it is not clear why (and no evaluation is done) to justify this on real workloads, and hence it is not clear whether the original formula works just as well.

The evaluation results didn't seem particularly impressive, and in fact their previously published work seems to outperform their current work in several figures.

In general, the authors may wish to investigate a wider array of related work, as several existing works target very similar problems and scenarios, and no cross-comparison was done. Making the underlying assumptions more clear would help as well.

A few more detailed comments:

1. Few typos. Both figure 10 and 11 show the traffic scenario III which is 50% TCP and 50% VBR traffic. However, the titles of the pictures say that these are 100% UDP.

2. I would recommend to enrich the background and related work section.

3. It would be interesting to see how the authors deal with the link/node failure and scalability issues in their follow-up research.

r1 - 15 Apr 2009 - 14:37:23 - AaronStriegel
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
Syndicate this site RSSATOM