=========================================================================== icnp16 Review #45A --------------------------------------------------------------------------- Paper #45: Enabling Router-Assisted Congestion Control on the Internet --------------------------------------------------------------------------- Overall merit: 3. Weak accept (Top 30% but not top 15%) Reviewer expertise: 2. Some familiarity ===== Paper summary ===== This paper present a mechanism to communicate information between routers and end systems to implement an explicit rate congestion control mechanism without requiring any changes to the packet format of TCP or IP protocols. Once a KA router computes an explicit rate for a TCP sender, it fragments data packets of this sender and the size of the first fragment endoces the computed explicit rate for this sender. The paper presents how the scheme could work in networks with mixed deployment (having a mix of KA enabled or non-KA enabled routers/end systems). The evaluations include NS3 based simulations, testbed experiments, and a wide area experiments. The results show improved performance compared to several TCP congestion control mechanisms including CUBIC, PCC, and FQ-CoDel. ===== Strengths ===== The proposed solution is effective in the sense that it requires no changes to packet formats to communicate the information needed to implement an explicit rate congestion control protocol. The scheme is incrementally deployable. KA enabled end systems can interact well with regular TCP senders by defaulting back to TCP under heavy congestion. ===== Weaknesses ===== The main contribution of the proposed scheme is to enable communication between routers and end systems. The paper does not include any discussion on the alternative mechanisms of doing so (if any) and how the proposed scheme is superior to those alternatives. ===== Comments for author ===== What are the alternative means (if any) of enabling communication between end systems and routers for implementing explicit congestion control? How does the proposed scheme compare to them? The paper includes various forms of evaluation results on the performance of the scheme under different work loads. What is the exact mechanism implemented in the KA routers to compute the rates for flows in those cases? What is the overhead of this computation for the KA routers? Does the scheme require maintaining per flow state (e.g., RTT for the flows or any other state)? =========================================================================== icnp16 Review #45B --------------------------------------------------------------------------- Paper #45: Enabling Router-Assisted Congestion Control on the Internet --------------------------------------------------------------------------- Overall merit: 3. Weak accept (Top 30% but not top 15%) Reviewer expertise: 3. Knowledgeable ===== Paper summary ===== The paper suggests a new mechanism for explicit congestion notification (ECN) for the Internet, which employs IP fragmentation to signal the explicit rate. The paper contains extensive simulation results and Internet measurements to characterize the system. ===== Strengths ===== - ECN is a recurring theme in the networking literature, which is yet to experience widespread use (despite inherent advantages). - A strength of the paper is the extensive evaluation methodology. ===== Weaknesses ===== - The novelty of the paper is conceptually quite modest, i.e., use fragmentation to signal the explicit rate. - There is no new insight on the understanding of ECN methods. ===== Comments for author ===== ECN is an appealing concept for congestion control, which has enjoyed interests over more than two decades. This paper does not present a new algorithm to determine the explicit rate (it uses RCP algorithm). Instead it suggests a new method to convey the explicit rate information. Specifically, it employs fragmentation and communicates the bottleneck rate in terms of the length of an IP fragment. A widely held belief (shared by this reviewer) is that IP fragmentation is not a beneficial concept and should be avoided. The sole purpose of protocols such as MTU Path Discovery is to avoid fragmentation of datagrams. IPv6 does not permit fragmentation at routers at all (it allows it at endpoints). It may be difficult to convince a community that seeks to retire IP fragmentation to use it for implicitly conveying information, which could be conveyed in many other ways (e.g., a user level protocol that is read by routers, a header extension). The rate encoding in Section II.A shows the drawbacks of re-tooling one scheme (IP fragmentation) for the purposes of another scheme (ECN). First of all, since the datagram must have a minimal length so that IP fragmentation is possible, the scheme is limited to full-sized (1500 byte) segments. Then, to use the odd 13-bit field for the fragment offset, there are constraints on the granularity of information. It is avoided by limiting the scheme to rates between 120 Kbps and 10 Gbps. The strength of the paper is the extensive evaluation, using simulation and Internet measurements. The results are not always surprising as one expects an explicit rate scheme to outperform end-to-end congestion control, and binary explicit congestion notification. The history of ECN is longer than provided in this paper. Different from the narrative of this (and many other papers), the concept emerged in the early 1990s in the context of congestion control in the ABR service of ATM. One of the first papers is: Yin, Nanying; Hluchyj, Michael G. ``On closed-loop rate control for ATM cell relay networks'' IEEE INFOCOM 1994 =========================================================================== icnp16 Review #45C --------------------------------------------------------------------------- Paper #45: Enabling Router-Assisted Congestion Control on the Internet --------------------------------------------------------------------------- Overall merit: 3. Weak accept (Top 30% but not top 15%) Reviewer expertise: 3. Knowledgeable ===== Paper summary ===== This paper proposes a mechanism that allows routers to communicate feedback on congestion-levels to end-systems, without adding additional header space. The idea is for routers to fragment incoming packets such that the packet size encodes a given congestion level. The paper instantiates this idea in the context of RCP, where routers communicate target sending rates using sizes of fragmented packets. The RCP-based prototype is evaluated through both in-lab and wide-are experiments, especially for partial-deployment scenarios. ===== Strengths ===== This main contribution of this paper is in evaluating the effectiveness of the kick-ass mechanism. For an enabling mechanism, it is important to consider several aspects, including incremental deployment, effectiveness (at communicating fine-grained feedback), and roadblocks --- each of these are explicitly addressed in the paper. This is noteworthy. ===== Weaknesses ===== While the paper does a good job of evaluating kick-ass under a wide variety of deployment scenarios, the evaluations seem to be still limited in two ways: * The experimental parameters seem to have been chosen randomly---for example, only a queue size of 1000 packets has been experimented with. It would seem that fragmentation (and the impact of packet drops on it) would manifest quite differently on paths with shallow buffered switches. Similarly, modern high-speed network paths have not been considered. * The paper seems to have also shied away from presenting evaluations that illustrate the limitations of the kick-ass mechanism (loss in efficieny at high speeds due to poor rate granularity). * Since kick-ass is a mechanism for routers to communicate feedback to end-systems, comparisons to other mechanisms for doing so should be included. There are also some concerns about the kick-ass idea itself, that are quite significant. First, in a high-speed world in which router designs are increasingly being stretched for fast-path processing, requiring routers to fragment packets according to a target sending rate does not seem like an idea that will be welcomed by router manufacturers or network operators. This is especially true in an IPv6 deployment, in which fragmentation by routers is inteded to be avoided altogether. Another significant concern is the fact that middle-boxes may drop such fragmented packets --- this can be an unknown factor that may end up being a firm roadblock to deployment of kick-ass. The fact that the paper found this on 8.3% of the paths considered is unnerving, not reassuring. That is a large fraction, and more importantly, a TCP connection would not know before-hand if the path it is about to use has this limitation. ===== Comments for author ===== NA =========================================================================== icnp16 Review #45D --------------------------------------------------------------------------- Paper #45: Enabling Router-Assisted Congestion Control on the Internet --------------------------------------------------------------------------- Overall merit: 4. Accept (Top 15% but not top 5%) Reviewer expertise: 4. Expert ===== Paper summary ===== The paper deals with incremental deployment of explicit-rate congestion control in the Internet that includes legacy routers and end systems. Leveraging the existing packet-fragmentation mechanism, the paper proposes to use packet-fragment lengths as implicit signals for communicating rate information from routers to end systems, and for sending RTT (round-trip time) information from end systems to routers. The extensive multifaceted evaluation convinces that the idea is practicable. ===== Strengths ===== The proposed idea is highly creative. The paper thoughtfully considers many relevant issues. The thorough multifaceted evaluation persuades that the proposal is practicable. ===== Weaknesses ===== Whereas the evaluation via simulation and real-world experimentation is appropriate for the given problem, the paper would strengthen its case by including theoretical insights. While being good overall, the presentation is occasionally careless about details. ===== Comments for author ===== The proposed idea is highly creative. In dealing with the difficult challenge of incrementally rolling out explicit-rate congestion control schemes, the paper identifies a new unorthodox solution compatible with the Internet protocol suite. The paper thoughtfully considers many relevant issues. The submission reports feasible and sufficiently accurate means to express rates and RTTs via packet-fragment lengths. Also, the design incorporates techniques for falling back to TCP congestion control in scenarios where congestion occurs at a legacy router or where the bottleneck link is shared with legacy TCP flows. The thorough multifaceted evaluation persuades that the proposal is practicable. The paper combines simulations, experiments in a real test bed, and measurements in the Internet. The evaluation convinces that the proposed idea is not only very clever but also workable. Whereas the evaluation via simulation and real-world experimentation is appropriate for the given problem, the paper would strengthen its case by including theoretical insights. In particular, stability of congestion control under the proposed feedback mechanism can be analyzed in a simple model, as was done in the following publication: "Feedback Modeling in Internet Congestion Control" by S. Gorinsky, Proceedings of Next Generation Teletraffic and Wired/Wireless Advanced Networking (NEW2AN 2004), February 2004. At the very least, the paper should cite the respective related work. While being good overall, the presentation is occasionally careless about details. In general, the material is organized well, and the ideas flow lucidly. The proper choice of plotted lines and font sizes makes the figures easily readable, even when the paper is printed in black and white. The minor presentation problems include inconsistent hyphenation (e.g., “end-points” vs. “endpoints” vs. “end hosts” vs. “end-hosts”) and incorrect hyphenation of adverbs ending in -ly (e.g., “lightly-congested”, “exponentially-distributed”, and “heavily-congested”). Overall, proposing the idea that is both highly creative and practicable distinguishes the paper favorably and qualifies it strongly for acceptance. Even though the approach is essentially to improve the system by working around the system, this is how many Internet innovations (CDNs etc.) have succeeded, and the extra overhead of the proposed scheme is relatively small. While a workable feedback scheme is only one hurdle for incremental deployment of explicit-rate congestion control, the paper tackles this hurdle successfully.