|
|
 |
|
|
|
Probe-Aided MulTCP: An Aggregate Congestion Control Mechanism
Appears in:
CCR January 2008 An aggregate congestion control mechanism, namely Probe- Aided MulTCP (PA-MulTCP), is proposed in this paper. It is based on MulTCP, a proposal for enabling an aggregate to emulate the behavior of multiple concurrent TCP connections. The objective of PA-MulTCP is to ensure the fair sharing of the bottleneck bandwidth between the aggregate and other TCP or TCP-friendly flows while keeping lightweightness and responsiveness. Unlike MulTCP, there are two congestion window loops in PA-MulTCP, namely the probe window loop and the adjusting window loop. The probe window loop constantly probes the congestion situation and the adjusting window loop dynamically adjusts the congestion window size for the arriving and departing flows within the aggregate. Our simulations demonstrate that PA-MulTCP is more stable and fairer than MulTCP over a wide range of the weight N in steady conditions as well as in varying congestion conditions. PA-MulTCP is also responsive to flow arrival/departure and thus reduces the latency of short-lived transfers. Furthermore, PA-MulTCP is lightweight, since it enjoys above advantages at the cost of only an extra probe window loop, which has a marginal influence on the implementation complexity. Finally, the design of PA-MulTCP decouples the congestion management from the other functionalities in the aggregate flow management. As a result, PA-MulTCP could be potentially applied to a wider range of scenarios, e.g. wireless TCP proxies, edge-to-edge overlays, QoS provisioning and mass data transport.
Public Review By:
Jon Crowcroft Despite some views on changing things (e.g. “Flow Rate Fairness: Dismantling a Religion” by Bob Briscoe fairly recently in these very pages), the Internet still runs smoothly because (at least partly) of TCP-friendliness. Actually, some people suggest that it is also possibly that most sites are access link speed limited, and the core networks are over-provisioned, but that is another story.
However, there are certainly links, and indeed end-to-end paths where there is plenty of capacity. These links are still shared, and capacity has to be assigned somehow, but why should it be assigned only in units of a single TCP flowshare's worth?
A goal in the original work on MulTCP was to provide a mechanism for single sources to allocate themselves multiple TCP’s worth of capacity, but remain collectively TCP-friendly. This paper extends that work to improve the fairness of MulTCP by provide a reference flowshare of a single TCP’s worth, and use this to control the window adjustment for the aggregate rate. The authors explain the algorithm and evaluate it using ns-2, and present the results clearly and effectively. There may be niche applications of this approach directly (as they mention, in storage area networks, or in some overlays), and the algorithm is of interest to those working on TCP-friendly flows of other type (e.g. multimedia).
We might talk about beating weapons of TCP-friendliness into flowshares.
Download:
PDF (238.9 KB) Share:
Twitter
del.icio.us