Dan Sandler: Existing methods of controlling TCP congestion fail to repair the basic flaw inherent in loss-based congestion detection: oscillation. The authors propose XCP, a variant of TCP in which fine-grained congestion control messages are accumulated in a packet as it travels through the network. The resulting message (an aggregate of congestion along the flow) is passed back to the original sender in a later acknowledgement, allowing the sender to fine-tune his rate. This avoids oscillation by not stressing the network to the point of congestion before signalling senders to change their behavior. In XCP, the concerns of fairness and efficiency are separated; the efficiency controller determines the feedback that must be sent to flow sources to mitigate congestion, and the fairness controller determines how to distribute this feedback among the flows. The chief concern with an approach such as that described here is the practicality of wide-spread deployment. The authors make an effort to address this question in Section 8, in which a case is made for gradual deployment of XCP as a core-router protocol or as an end-to-end protocol alongside TCP in the Internet at large. Unfortunately, XCP is useless in the real Internet unless all the routers along a path support it; this sort of adoption profile can be called "incremental", but it is likely to be a very slow adoption indeed (a very shallow exponential curve of XCP-deployed nodes to complete XCP flows through the network). A huge portion of the Internet would need to be XCP-aware before any end host would likely see a benefit. For this reason it seems tempting to deploy XCP purely in the core of the network. Perhaps XCP will help with the internal congestion and queueing of the core, however, traditional TCP senders will be unresponsive to the subtle congestion signals of core-deployed XCP and may still oscillate near the point of congestion. *********************************************************************** Yan-jun Sun: Paper review for comp620 Name: yanjun Paper Title: Congestion Control for High Bandwidth-Delay Product Networks Assumptions: 1. focusing more on the networks with high bandwidth-delay product (optical, satellite) than in conventional networks 2. where TCP is inefficient & not stable (where short-term flows not benefit too much ) Target: solve TCP's limitations in the networks with high bandwidth-delay product. ( XCP is efficient, fair, scalable and stable which turns out to outperforms TCP in conventional networks ) Contributions: 1. simple calculation at intermediate nodes, no per-flow operation, so scales well fluid model, fixed parameters, not depending on capacity, delay, number os sources... 2. idea of decoupling the effectiveness and fairness control 3. ourperform TCP in conventional networks & more suitable to networks with high bandwidth-delay product 4. packet headers contain control states, and routers write feedback into the headers 5. *point out using "loss" for congestion control is not suitable -> precise feedback, tight control (MIMD for efficiency control + AIMD for fairness control, not clear about the motivations 6. ns evaluation code and binary code for Freebsd is available online Objections: 1. additional overhead for the control state, and needs modifications both at the ends and intermediate routers 2. help distinguishing error lesses from congestion losses by observing the contradiction between the explict feedback and the operation (to what degree?) 3. detect misbehaving sources? what about misbehaving routers 4. TCP has a variant (?name) for short-term flows to increase the window size quickly 5. "the router maintains a per-link estimation-control timer that is set the most recent estimate of the average RTT", how is this RTT defined? What about the case that return path is different from forward path? 6. "we chose the control above (MIMD + AIMD) because our analysis and simulation demonstrate their good performance", only use simulation for performance evaluation, "most of our simulations use the topology in Gigure 2" what if the scenarios for simulations are not complete? 7. "use long-lived FTP flows", no evaluation on how XCP benefits the short-term traffic and FTP is not as bursty as Http traffic 8. how does XCP fit into the existing QoS control framework since it tries to provides fairness among flows? -- ************************************************************************** Andreas Haeberlen: [ The following text is in the "ISO-8859-1" character set. ] [ Your display is set for the "US-ASCII" character set. ] [ Some characters may be displayed incorrectly. ] The authors present a new transport protocol called XCP that is designed to solve efficiency issues with the current TCP protocol in scenarios with high link bandwidth and/or high end-to-end delay. In an XCP network, routers provide explicit congestion feedback in a special header, which is reflected back to the sender and used there to adjust the congestion window. The feedback is given in such a way that link utilization is maximized, while still maintaining fairness between the different flows. The paper is well-written, addresses a highly relevant problem, and provides a detailed analysis of the proposed solution. Also, the evaluation results are very promising. However, some of the assumptions made in the paper are unrealistic, and deployment is a big weakness that should have been discussed in more detail. Overall, I still think this is a very nice paper. That said, the authors clearly simplified the problem quite considerably to make it tractable for their control-theory approach. But since XCP is proposed as a replacement for TCP, it would have to be evaluated in the same complex scenarios. For example, it is not clear how route instabilities, multi-path flows, or a high number of bursty mini-flows would affect XCP's performance. Also, the topologies used for evaluation are extremely simple, and even for the moderately complex 'parking lot' topology, link utilization already drops noticeably. I am worried that interactions between different routers may lead to sub-optimal performance in more complex networks. While XCP can potentially yield significant benefits, it can only deliver them when most of the hosts _and_ routers are XCP-enabled. If even a single router along the path does not support XCP, the bottleneck bandwidth cannot be estimated properly. Hence, XCP is not very useful for existing large-scale networks such as the internet. ********************************************************************** Atul Singh: Title: Congestion control for high bandwidth delay product networks Points in favor: This paper tries to solve the problem with TCP at high bw-delay product networks, i.e. time to get full throuhgput of the link and the oscillations. The idea is to use the information available regarding the congestion from the core of the network, rather than end hosts trying to estimate/guess the congestion and then take measures against congestion. Moroever, they decouple congestion control from fairness control, which I think is a major point of the paper. Thier main contribution is to use results from control theory and applying it to a complex congestion control system of IP networks. XCP outperforms TCP in high bw and delay settings. Points against: Increasing the overhead of routers. For each link, the router has to estimate the average RTT on the flows going on it and then use it to trigger control feedback. I am conjecturing that this is an optimization to "not" to do per flow compuation and use the RTT for each flow, but to use the average RTT and do it per link. The results show that in typical internet, some variants of current techniques are equally good. E.g. in web like environments, XCP is as good as AVQ, similarly in congested queues experiment. This paper raises an important question on how to detect congestion in the network. One approach is to not modify routers and use end hosts to estimate the cause, other one is to use the valuable information at bottleneck routers to detect it and inform intelligently the end hosts. Now the question is, should routers enforce policies or just let end hosts inform it about the congestion and let them make a decision. The point is if we are allowed to use the routers, what else can we do? ************************************************************************ Johnny Ngan: Congestion Control for High Bandwidth-Delay Product Networks This paper proposes eXplicit Control Protocol, XCP, which is a generalization of the Explicit Congestion Notification proposal. The protocol is based on one simple idea: instead of sticking to the end-to-end principle as in TCP, XCP completely relies on the router to give feedback to the senders to control the flows. As such, the routers, particularly the bottleneck ones, would be able to control congestion and fairness among flows, thus resulting in a more efficient and better utilized network. It also does not require per-flow-state in the routers, which is important for scaling. The paper is significant, as it provides a useful framework of designing such protocols, and rationale and analysis to justify its choices and parameters. Like many other papers, however, the authors tend to give equations used in the protocol without enough explanations and discussions. The better performance against TCP Reno is expected, and it comes a little surprised that they didn't compare against TCP Vegas. There are problems that need to be solved before deployment. For example, the requirement for each router to perform some computation for each packet is not extremely desirable. Also, XCP requires all routers in the path to be XCP-enabled to work; a single, non XCP-enabled router would make the protocol useless. ************************************************************************ Ansley Post: This paper presents a scheme for imporoving on TCP. The problems of TCP in certain of type of networks are demonstrated and the defeciencies are explained. They present a replacement protocol (XCP) which improves on TCP in almost every way possible. Experimentation and results are presented demonstrating that XCP is indeed useful. The problem I have with this paper is it starts from the point, "What would we do if we could start from scratch". While it is an interesting thought experiment it is hard to imaging how it would work in real life. The routers would have to be altered in order to use this protocol, and I can't imagine every router in the internet could be replaced. The paper mentions a version of xcp that can coexist with TCP(and the acomponaying routers) but this dilutes some of the advantages of using XCP. -- *********************************************************************