XCP was designed keeping in mind the increased use of high bandwidth and latency networks. The authors argue that conventional TCP implementation and congestion control schemes falter in settings that involve high bandwidth links and large delays. Moreover with the growth of the Internet we now have a mix of networks that have varied bandwidth and delays. This raises the need to make sure that the transport layer protocol is stable in extreme scenarios and handle congestion control. Also, TCP biases against flows that has large round trip time and short flows get stuck in the slow-start phase.
XCP proposes to solve these problems. The authors propose modifying explicit congestion notification (ECN) and have routers inform senders about the degree of congestion at the bottleneck. They argue that a binary variable is not enough to convey congestion information. Sending rate of a source should be adjusted based on RTT and fairness should be independent of the number of flows. They also decouple utilization control from fairness.
Each XCP packet contains a congestion header that has H_cwnd, H_rtt and H_feedback. The sender sets H_cwnd and H_rtt. Routers along the path update H_feedback using EC (efficiency controller) and FC (fairness controller). EC uses MIMD while FC uses AIMD. The receiver copies H_feedback to ACK and the sender updates its CWND based on the feedback.
This paper was insightful to understand the requirements for high speed networks. How the current implementation of TCP does not cater to these requirements and what needs to be done. With the evolution of Internet happening at such fast pace we need to always keep in mind how current protocols scale with respect to today's requirements. I would recommend keeping this paper in the syllabus.
XCP outperforms TCP because it sends complete information of the degree of congestion instead of sending a bit signaling congestion. Decoupling FC and EC enables utilizing spare bandwidth and it also considers the delay in feedback while updating CWND. It is scalable because this does not require per-flow state to be stored at the routers.
One thing that seemed weird is that XCP is depending on the feedback sent in the ACK packet. The authors say that packet losses happen rarely but if a router is malicious or due to some other reasons that ACK is lost or it is modified then XCP can become unstable. Also, XCP is relying that the sender updates H_cwnd and H_rtt as per the rules. In case of an ill-behaved user XCP can be fooled to work incorrectly.
XCP proposes to solve these problems. The authors propose modifying explicit congestion notification (ECN) and have routers inform senders about the degree of congestion at the bottleneck. They argue that a binary variable is not enough to convey congestion information. Sending rate of a source should be adjusted based on RTT and fairness should be independent of the number of flows. They also decouple utilization control from fairness.
Each XCP packet contains a congestion header that has H_cwnd, H_rtt and H_feedback. The sender sets H_cwnd and H_rtt. Routers along the path update H_feedback using EC (efficiency controller) and FC (fairness controller). EC uses MIMD while FC uses AIMD. The receiver copies H_feedback to ACK and the sender updates its CWND based on the feedback.
This paper was insightful to understand the requirements for high speed networks. How the current implementation of TCP does not cater to these requirements and what needs to be done. With the evolution of Internet happening at such fast pace we need to always keep in mind how current protocols scale with respect to today's requirements. I would recommend keeping this paper in the syllabus.
XCP outperforms TCP because it sends complete information of the degree of congestion instead of sending a bit signaling congestion. Decoupling FC and EC enables utilizing spare bandwidth and it also considers the delay in feedback while updating CWND. It is scalable because this does not require per-flow state to be stored at the routers.
One thing that seemed weird is that XCP is depending on the feedback sent in the ACK packet. The authors say that packet losses happen rarely but if a router is malicious or due to some other reasons that ACK is lost or it is modified then XCP can become unstable. Also, XCP is relying that the sender updates H_cwnd and H_rtt as per the rules. In case of an ill-behaved user XCP can be fooled to work incorrectly.
1 comment:
Note that as long as some ACKS reach the sender (and they shouldn't be lost at anything approximating a high rate if the network is kept out of congestion), it should be able to adjust its CWND in a reasonable fashion. It is true that that adjustment may lag, and so there can be some dynamic effects problems. It is interesting that I am unaware of papers that look carefully at the implications of lost congestion signals in the proper execution of proposed algorithms. If worse comes to worse, you do behave like TCP in the face of lost packets and time outs.
Post a Comment