WWW/Internet - Portal do Software Público Brasileiro

ISBN: 978-972-8939-25-0 © 2010 IADISCTCP is a novel TCP congestion control algorithm proposed by Microsoft to optimize TCP for use withconnections with large congestion windows. The main idea behind CTCP is to add a scalable delay-basedcomponent to the standard TCP's loss-based congestion control. The sending rate of CTCP is controlled byboth loss and delay components. It has become a highly relevant protocol due to its worldwide adoption, aspart of Windows 2008 Server and Windows Vista. CTCP is a relatively new proposal and, to the best of ourknowledge, there is no extensive evaluation of this protocol. The most relevant performance evaluation ofCTCP was carried out by the authors on their test-bed. CUBIC is a novel TCP congestion control algorithmthat adopts a cubic function for congestion window increase in the sender’s side, with the inflection point setto the window prior to the congestion event, instead of a linear function. The authors of CUBIC argue that itimproves scalability and stability under fast and long distance networks. CUBIC has become a highlyrelevant protocol due to its adoption worldwide as the current Linux kernel TCP stack implementation.Prior works (Mattsson, 2004) have compared DCCP with standard transport protocols, using discreteevent simulations. However, such works have drawbacks, so that they have measured a single protocol perlink, using errorless links and constant bit rate traffic. Through simulations, Takeuchi et al. (2005) havecompared the fairness of UDP, DCCP CCID2, TCP SACK, TCP Reno, and TCP New Reno. Similarly,Bhatti et al. (2008) have compared the fairness of TCP New Reno, BIC-TCP, CUBIC, and DCCP CCID2.Sales et al. (2008) have conducted experiments on a wireless network to measure performance, delay, andfairness of multimedia traffic on UDP, DCCP CCID2, DCCP CCID3, and CUBIC.This paper belongs to a line of research that attempts to evaluate DCCP protocol in an effort to measurehow the congestion control mechanisms perform in several scenarios using distinct traffic patterns. In thispaper, we compare the performance of DCCP variants CCID2 (Floyd & Kohler, 2006) and CCID3 (Floyd etal., 2006), CTCP, and CUBIC, based on VoIP and CBR traffic patterns. We consider a topology where theprotocols are grouped in pairs and contention occurs as data packets traverse bottleneck links, so that eachpair of protocols must fight for the link bandwidth. Hence, in addition to performance, it is possible tomeasure the fairness of the protocols along the simulations.The remainder of this paper is organizes as follows. Section 2 presents a brief description of the protocolsthat we consider in this work. Section 3 details the methodology to carry out the performance comparison,and presents the simulation results. Finally, Section 4 presents our conclusions.2. PROTOCOL DESCRIPTION2.1 DCCPThe Datagram Congestion Control Protocol (DCCP) (Kohler, et al., 2006) is a transport protocol thatprovides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitablefor applications that transfer fairly large amounts of data and that can benefit from control over the tradeoffbetween timeliness and reliability. DCCP is easily extensible to other forms of unicast congestion control.Two congestion control mechanisms are currently specified: TCP-like Congestion Control (CCID2) (Floyd& Kohler, 2006) and TCP-Friendly Rate Control (TFRC) (CCID3) (Floyd et al., 2006). TCP-like CongestionControl CCID2 sends data using a close variant of TCP's congestion control mechanisms, incorporatingselective acknowledgements (SACK). CCID 2 is suitable for senders which can adapt to the abrupt changesin congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestioncontrol and particularly useful for senders which would like to take advantage of the available bandwidth inan environment with rapidly changing conditions. CCID3 is a receiver-based congestion control mechanismthat provides a TCP-friendly sending rate while minimizing the abrupt rate changes characteristic of TCP orof TCP-like congestion control. The sender's allowed sending rate is set in response to the loss event rate,which is typically reported by the receiver to the sender. TCP-Friendly Rate Control for Small Packets(TFRC-SP) (CCID4) (Floyd & Kohler, 2009) is currently specified, but still incipient and it is not included inthis work.To support timeliness packet delivery, DCCP has a feature called late data choice, where the applicationcan change what's sent very late in the process, even if the application data is downwards in the networkstack. This feature is advantageous depending on the contention, because some late packets may be irrelevantafter a deadline.212