Reviews for Wischik11MPTCP
Rodrigo Fonseca
Zhiyuan "Eric" Zhang
Paper Title
Design, implementation and evaluation of congestion control for multipath TCP
Authors
Damon Wischik, Costin Raiciu, Adam Greenhalgh, Mark Handley
Date
NSDI 11'
Novel Idea
This paper presents a congestion control algorithm for multipath TCP. The main question it tries to answer is how to share network capacity efficiently and fairly among multipath TCP flows.
Evidence
The congestion control algorithm is evaluated in three scenarios: multihomed Internet servers, data centers and mobile devices. For each scenario, the authors run simulations with simulators and their Linux implementation of multipath TCP.
Main Result
The result shows benefits in all three scenarios:
1. For multihomed Internet servers, multiple transport can balance traffic/congestions (even when a minority of flows are multipath TCP).
2. For data center, the algorithm performs well in all three traffic patterns.
3. For wireless clients, the experiment shows that the device can use both 3G and WiFi interfaces simultaneously, and also provide as much as throughput as single-path users.
Related Work
This paper is based on multipath TCP, which proposed by IETF working group:
A. Ford, C. Raiciu, and M. Handley. TCP extensions for multipath operation with multiple addresses, Oct 2010. IETF draft (work in progress).
There are also several works on multipath transport protocol such as SCTP. While those works are mainly about protocol design, this paper focuses on designing a congestion control scheme.
Reproducibility
It should be fairly easy to reproduce, although it requires some work to implement MPTCP first.
Comment
The authors very clearly described their algorithm and how they arrive at the design step by step (with nice figures). I think it's really clear to solve one piece of the question at a time, and then combine them all together. The experiments are well-designed so that the authors can make a solid conclusion. I enjoyed reading this paper overall.
Shu Zhang
The paper proposes a congestion control method for multipath TCP in order to let multipath TCP protocol behave in a reasonable and efficient way. Then it tested the behavior in three scenarios to examine the generality of the algorithm. Also the implementation is introduced. So it is a quite comprehensive one. This is a new viewpoint to see the load-balancing/bottleneck problems, typically in the data centers.
There are congestion control methods for MPTCP but with these algorithms have problems. By order, regular TCP might cause fairness problems. EWTCP will cause performance problems (multi flows don’t beat single flow). Although COUPLED solves the previous problem, but if RTTs are not equal, it will prevent the connection to perform well. So SEMICOUPLED could use some flows to detect possible path and distribute weights on multiple paths,but the definition of the weight parameter is undetermined.
The paper proposes two requirements when designing the congestion control algorithm for multipath flows, one is the aggregate throughput should be the same if single-path method is adopted; the other is the multiple flows should not harm other flows. Another angle to look at the problem is that the bandwidth allocation should be located on the diagonal line of figure 6.
MPTCP is designed according to the requirements.
Simulations are carried out on three scenarios to compare multiple congestion control ways. In a multihomed internet server, MPTCP is close to the best generally but not always the best. No matter COUPLED or EWTCP could perform not well under certain configs. In this part, ECMP is taken as a test baseline. As we can see, in both FatTree and BCube, MPTCP performs generally the best. The last scenario is the wireless connections with WIFI and 3G, which are two connection types with different drop rates and RTTs. Implementation of the protocol is an extension of TCP and is discussed in the end.
Questions
For COUPLED algo, w_total is reversely proportional to the probability of the loss rate, and the window size increase is proportional to w_total and reversely proportional to w_total, so path with higher P will increase more quickly and decrease more slowly ? But why the paper said the paths with higher P will finally have window sizes of 0? Admittedly it is intuitively true, but looking into the description of algorithm, it is saying the opposite thing? Or my understanding goes wrong?
Jeff Rasley
On Wednesday, April 3, 2013 10:03:44 PM UTC-4, Rodrigo Fonseca wrote:
Christopher Picardo
Paper Title:
Design, Implementation and Evaluation of Congestion Control for multipath TCP
Authors:
Damon Wischik, Costing Raiciu, Adam Greenhalgh, Mark Handley
Date:
In Proceedings of the 8th USENIX conference on Networked systems design and implementation 2011
Novel Idea:
The paper describes the design of a multipath congestion control algorithm which seamlessly balance traffic over 3G and WiFi radio links, and allows continuous and rapid rebalancing on short timescales a wireless conditions hange.
Main results:
The multipath congestion control algorithm works because improves throughput and fairness when compared to single-path TCP. Specifically, the algorithm adapts the subflow windows of a multipath TCP to attain the maximum performance possible while coexisting with the normal TCP traffic.
Experiment Results:
- To attain fairness at shared bottlenecks, they suggest to run a weighted version of TC on each subflow.
- To choose efficient paths, a multipath flow should shift all its traffic onto the least-congested path.
- An interesting consequence of moving traffic away from more congested paths is that loss rates across the whole network will tend to be balanced.
- When dealing with RTT mismatch, switch from window-based control to rate-based control. However, this radical change to TCP is not practical; the current TCP architecture is not ready for it.
- When adapting to load changes, always keep sufficient traffic on other paths, as a probe, so that you can quickly discover when they improve.
- When compensating for RTT mismatch, multipath provides, as much throughput as single-path TCP, and a multipath flow should not take more capacity on any path or collection of paths than a single-path TCP flow.
- MPTCP performs well across a wide range of traffic patterns.
- Reference to Hedera: An alternative solution for balancing traffic is to use a centralized scheduler which monitors large flows and solves an optimization problem to calculate good routes for them.
- For multipath wireless clients, MPTCP gives users at least as much throughput as single-path users.
Impact:
The main impact is the layout and demonstration of a working congestion control algorithm for multipath TCP.
Prior work:
EWTCP, R-MTP, Hedera, BitTorrent, Microsoft’s Compound TCP.
Question:
Open questions (1) how network capacity should be shared efficiently and fairly between competing flows? … still work in progress and there is room for improvement. (2) How should be data sequence numbers and data acknowledgements be encoded in TCP packets?
Papagiannopoulou, Dimitra
Title: Design, implementation and evaluation of congestion control for multipath TCP
Authors: Damon Wischik, Costin Raiciu, Adam Greenhalgh, Mark Handley
University College London
Novel Idea: In this paper the authors design, implement and evaluate, a multipath congestion control algorithm that can yield performance and fairness improvement compared to single-path TCP.
Main Result: The main result of the paper, is the design and implementation of a congestion control algorithm for multipath TCP, MPTCP. The paper shows that the algorithm can balance traffic over 3G and WiFi radio links while improving aggregate throughput without harming other traffic. It should be also beneficial to the operation of the Internet since it can balance congestion. The proposed algorithm is safe to deploy and can yield performance improvements.
Evidence: The authors describe existing algorithms, in order to explain how they arrived at the design of their algorithm. They present the regular TCP window-based congestion control algorithm, EWTCP and COUPLED, and discuss their weaknesses through examples that demonstrate specific problematic scenarios during their application. Then, they investigate the operation of MPTCP in three specific applications, in order to make it robust under a wide range of environments: A multihomed Internet server, a data center and a mobile client. In the first case, after performing a static load balancing simulation, they illustrate the congestion imbalance as a function of the link capacity, where MPTCP was found to perform better than EWTCP but worse than COUPLED. At dynamic load balancing, MPTCP yielded better throughput than COUPLED and slightly worse than EWTCP. For the data center environment, they simulated three traffic patterns, all consisting of long-lived flows, and reported throughput and loss rate for the SINGLE-PATH, EWTCP and MPTCP. MPTCP performed well at all the traffic patterns. Even though EWTCP performed as well as MPTCP in some cases, it is less fair. In the multipath wireless client case, with competing flows, only MPTCP got close to the correct total throughput. There is a wide variety of results that are presented in the paper, that demonstrate the proposed algorithm's strengths.
Prior Work: This paper presents a congestion control algorithm for multipath TCP. Multipath TCP, was proposed by the IETF working group [7] and it allows a single data stream to be split across multiple paths. This can improve reliability, mobility and load balancing at multihomed servers and data centers. The authors compare their algorithm against existing congestion control algorithms such as Regular TCP and its newer versions [24, 9], as well as weighted TCP [5], EWTCP [11] and COUPLED [15, 10].
Competitive Work: There have been other works that also built multipath transport protocols [13, 27, 18, 12, 14, 6, 23, 7] but their key goals were to achieve robustness to long term path failures and to short term variations in the conditions on the paths, while the main issues this paper deals with are how to make efficient load balancing and flow control, how to ack etc. pTCM [12] CMT over SCTP[14] M/TCP [23] had some fairness issues, mTCP [27] was not clearly robust, R-MTP [18] imposed certain limitations on its application. ECMP [25] achieved load balancing at the flow level without the involvement of end-systems and could complement Multipath TCP. Horizon [20] was targeted to load balancing at the network layer for wireless mesh networks, but some theoretical work on it showed that it may have some inefficient outcomes in certain cases [1]. Finally, BitTorrent [4] is an example of application layer multipath.
Reproducibility: The results of this paper are reproducible.
Criticism: What is really nice about this paper, is that the authors analyze existing algorithms and present their weaknesses through specific scenarios in order to come up with an efficient design for their proposed congestion control algorithm. Multipath TCP raises several questions in terms of load balancing efficiency and fairness between competitive flows, and this paper presents an algorithm that is efficient and robust across a wide range of scenarios and environments. The authors are honest about the fact that their algorithm is not optimal and that it requires further theoretical support, but its design gives a solution to some limitations and problems of other existing algorithms.
Question for Class Discussion: The authors mention that they restrict their attention to end-to-end mechanisms for sharing capacity and they assume that each TCP flow can control how much traffic to send on each path but cannot specify the paths themselves. What inefficient outcomes could arise if both the end-systems and the core participated in balancing traffic?
--
You received this message because you are subscribed to the Google Groups "CSCI2950-u Spring 13 - Brown" group.
To unsubscribe from this group and stop receiving emails from it, send an email to csci2950u-sp13-b...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
kmdent
Design, implementation and evaluation of congestion control for multipath TCP
by Damon Wischik, Costin Raiciu, Adam Greenhalgh, Mark Handley
Novel Idea: Split a TCP flow across multiple paths while maintaining the efficiency and fairness of regular TCP. They restrict their mechanisms for fairness and congestion control to the ends of the flow. Each of the flows manages it’s own congestion window, and is increased separately.
Main Result: The MPTCP congestion is separate from the regular TCP congestion control because if they used that algorithm, MPTCP would have double the throughput of single path. If they used EWTCP, an equal weighted version of TCP congestion control, there would not be efficient use of the network. The COUPLED algorithm solves the fairness problem as well as making efficient choices using only one hop paths. SEMICOUPLED is similar to COUPLED, but it still tries to keep a moderate amount of traffic on each path while still favoring less congested paths.They modify the SEMICOUPLED algorithm so that no path can take more than a single path TCP flow. The new algorithm works over lossy links, is fair, and will almost always improve efficiency on networks where there is more than one path.
Evidence: They test the algorithm on a multihomed internet server, a data center, and a mobile client. They static load balancing in a stable environment with long lived flows. They test dynamic load balancing with two links and with one bursty flow. For data centers they test using both fat trees and BCubes. On mobile networks they test with a single flow and on multiple competing flows
Impact: Multipath TCP has had a large impact, but as far as this congestion control scheme is concerned, I am not sure.
Prior Work: Multi-path TCP (2006), and Stability of end-to-end algorithms for joint routing and rate control(2005)
Competitive work: pTCP, CMT, and M/TCP.
Reprod: This paper is very reproducable. They outline both the algorithm, and issues with the implementation.
Zhou, Rui
Title:
Design, implementation and evaluation of congestion control for multipath TCP
Author:
Damon Wischik, Costin Raiciu, Adam Greenhalgh, Mark Handley
Novel Idea:
This paper proposed several variants of Multipath TCP including MPCTP, EWTCP and Coupled as well as some further variants based on them and procide evaluation for real world senarios simulation. Comparing to classical TCP, multipath TCP can lead to realiability and more effcient use of Network Resources.
Summury:
[MPTCP]
* general description(CG):
For incoming Acks in subflow r, compute formula (1) and add to
Window of r. Do MD on W of r when a loss happens in r.
[EWTCP]
*general description(CG):
Similar to MPTCP, but For each ACK on pathr, increase window wr
by a/Wr. Use variable a to change aggressivness.
*feature
Weighted Multipath TCP connection is friendly to classic TCP connection. But it could under utilize the network because of the lack of ability to shift traffic to less-congested link.
[Coupled]
*general description(CG):
For each ACK on path r, increase window Wr by 1/W_total.
For each loss on pathr, decrease window Wr by Wtotal/2.
The Window for total is solved by equation (2)
*feature
Coupled MPTCP is smart enough to shift traffic to less congested links.
Naive Coupled MPTCP can be trapped when one of the links is non-traffic.
[Semi-Coupled]
*gneral description:
Instead of increase window by 1/W_total, we now increase it by a/W_total, and a is a variable to control aggressiness.
*feature
SEMICOUPLEDtries to keep a moderate amount of traffic on each path while still having a bias in favour of the less congested paths. This solves the problems of track.
[EWTCP variant]
*genral description
To cope with RTT mismatch, a modification on EWTCP is presented as:
Each ACK on subflowr, increase the window Wr by min(a/w_total, 1/Wr).
Each loss on subflowr, decrease the window wr by Wr/2.
a is computed according to (5).
[Too fair?]
Trying to be absolutely fair to classic TCP means we restrict ourselves when MPTCP can do better than classic TCP. For example, when we add a 3g link to a wifi link and only present one flow, by using hypothesis zero traffic flows, MPTCP can natualy obtain full utilization of the network resource and exceedong the fairness goal, which is more like a drawback of classic TCP in this senario.
[Evaluations]
There are three chapters of evaluations. The intution is that different variants perform better in different senarios. But overall MPTCP is good at traffic balancing and effective usage of network resouces. And the authors tried to make their MPTCP implementation TCP friendly and can be drop-in to current network.
A really nice thing is too see MPTCP nicely fits in current data-center network infustructure.
Questions:
1. In MPTCP, why in formula (1), we have to consider a "each subset S belongs to R" ?
2. Are we assuming NO udp in datacenter Networks?
Shao, Tuo
Place, Jordan
Multipath TCP looks to take advantage of multiple paths between
hosts in a network at the granularity of TCP. The idea of setting up
multiple subflows of data which get ordered by the receiver seems
simple enough, but it is non-trivial to get these subflows to play
nicely with single TCP flows. The authors of this paper outline
previously proposed way of implementing congestion control. The
simplest way is to merely split the bandwidth evenly across all paths
being taken, but this allows a multipath TCP flow to get much more
bandwidth than is fair. Another means attempts to prevent multipath
TCP from performing worse in any case than a single flow would, but it
suffers from "trap" issues.
The paper offers a variety of test environment results ranging
from mobile laptops to data centers. MPTCP performs extremely well
compared to a single TCP flow in all these environments. The authors
meet their outlined goal of achieving fairness with single TCP flows
while still providing greater throughput.
At the end, the authors point out how powerful MPTCP could be when
complemented by ECMP. The multiple paths available in a FatTree
network are perfect for stripping flows across and dividing flows
across paths removes the need for fancy dynamic schedulers like
MicroTE or Hedera.
I am wonder if reordering issues (especially due to a lossy path)
impact jitter significantly. It seems as if multipath TCP may only be
a good option for flows that require higher throughput but low jitter
guarantees (unless you are in a data center and can promise low packet
loss on all paths?). Additionally, it is worth noting that MPTCP faces
a whole slew of issues when trying to navigate the public Internet:
https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf
Jeff Rasley
On Wednesday, April 3, 2013 10:03:44 PM UTC-4, Rodrigo Fonseca wrote: