A Survey on TCP-Friendly Congestion Control 童曉儒 教授 國立屏東科技大學 資管系

Outline Introduction TCP and TCP Friendliness Classification of Congestion Control Schemes Window-Based vs. Rate-Based Unicast vs. Multicast Single-Rate vs. Multi-Rate End-to-End vs. Router-Supported Rate Adaptation Protocol (RAP) Receiver-driven Layered Congestion Control (RLC) Conclusions

Introduction(1/4) Not all Internet applications use TCP and therefore do not follow the same concept of fairly sharing the available bandwidth. TCP-based protocols applications Hypertext Transfer Protocol (HTTP) Simple Mail Transfer Protocol (SMTP) File Transfer Protocol (FTP)

Introduction(2/4) Non-TCP traffic applications is constantly growing. Internet audio players IP telephony Videoconferencing real-time applications Upon encountering congestion All contending TCP flows reduce their data rates in an attempt to dissolve the congestion. The non-TCP flows continue to send at their original rate.

Introduction(3/4) TCP congestion control end-to-end mechanism assumes that end systems correctly follow the protocol Coexistence of TCP flow and non-TCP flow (or faked TCP flow) If one is greedy  unfairness If one is malicious  congestion, DoS

Introduction(4/4) Since these applications commonly do not integrate TCP-compatible congestion control mechanisms. To define appropriate rate adaptation rules and mechanisms for non-TCP traffic that are compatible with the rate adaptation mechanism of TCP. These rate adaptation rules should make non-TCP applications TCP-friendly, and lead to a fair distribution of bandwidth.

What is congestion ?(1/2) What is congestion ?  The aggregate demand for bandwidth exceeds the available capacity of a link. What will be occur ?  Performance Degradation Multiple packet losses Low link utilization (low Throughput) High queueing delay Congestion collapse

What is congestion ?(2/2) Different sources compete for resources inside network Why is it a problem? Sources are not aware of current state of resources Sources are not aware of each other In many situations will result in < 1.5 Mbps throughput (congestion collapse) 10 Mb/s 100 Mb/s 1.5 Mb/s

RTT and RTO AB ACK Sample RTT Original transmission retransmission RTO X

Modeling TCP Throughput(1/2) A basic model that approximates TCP ’ s steady-state throughput T The throughput of TCP depends mainly on the parameters RTT tRTT, retransmission timeout value tRTO, segment size s, and packet loss rate p. Using these parameters, an estimate of TCP ’ s throughput can be derived. This model is a simplification in that it does not take into account TCP timeouts.

Modeling TCP Throughput(2/2) An example of a more complex model of TCP throughput b is the number of packets acknowledged by each ACK and Wm is the maximum size of the congestion window. The complex model takes into account rate reductions due to TCP timeouts.

Additive Increase Multiplicative Decrease (AIMD) (1/3) multiplicative decrease: cut CongWin in half after loss event additive increase: increase CongWin by 1 MSS every RTT in the absence of loss events: probing Long-lived TCP connection

Additive Increase Multiplicative Decrease (AIMD) (2/3) AIMD(a,b), with window size W Increase parameter a, Decrease parameter b Each RTT increase window to W+a Upon loss event decrease to (1-b)W TCP uses AIMD(1, ½ ) Increase by 1 every RTT Decrease by ½ upon loss Smoother should have b < ½ TCP-friendly should then have a < 1

Additive Increase Multiplicative Decrease (AIMD) (3/3) (round trips)

Slow Start Example 1 One RTT One pkt time 0R 2 1R 3 4 2R R

Example assumes that acks are not delayed Slow start Congestion avoidance Slow start threshold

Congestion Control -- Timeout ssthresh = 8 ssthresh = 10 cwnd = 20 After timeout

TCP Saw Tooth Behavior Time Congestion Window Initial Slowstart Fast Retransmit and Recovery Slowstart to pace packets Timeouts may still occur

TCP ’ s Rate Control [Reno, NewReno] time congestion window size (cwnd) limit ssthresh AIMD slow start phase Additive Multiplicative congestion avoidance phase

TCP Window Flow Control acknowledgedsentto be sentoutside window Source Port Dest. Port Sequence Number Acknowledgment HL/Flags Window D. Checksum Urgent Pointer Options.. Source Port Dest. Port Sequence Number Acknowledgment HL/Flags Window D. Checksum Urgent Pointer Options.. Packet Sent Packet Received App write

Sliding Window Flow Control Sliding Window Protocol is performed at the byte level:

TCP Fairness Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K TCP connection 1 bottleneck router capacity R TCP connection 2

TCP Friendliness 「 their long-term throughput does not exceed the throughput of a conformant TCP connection under the same conditions 」 TCP friendliness ensures that coexisting TCP flows are not treated unfairly by non-TCP flows. Throughput The effect of a non-TCP flow on competing TCP flows rather than on the throughput of the non-TCP flow.

TCP-Friendly Flows Unresponsive flows get unfair share of network bandwidth and AQM techniques will punish them. Streaming flows need to be TCP-Friendly. A TCP-Friendly flow ’ s bandwidth is no more than a conformant TCP flow running under comparable network conditions.

TCP friendly congestion control(1/3) TCP friendly: a protocol that behaves like TCP Backs off if congestion and uses a fair share of resources. Protocol that obeys TCP long term throughput relation. Internet requirement: new transport protocols must be TCP friendly Backs off if congestion and uses a fair share of resources. Applies also to application layer protocols transmitting over UDP, e.g., real time telephony or streaming applications. Rate control implemented on top of UDP as part of application.

TCP friendly congestion control(2/3) Non-TCP friendly: A protocol that takes more than its fair share of bandwidth (greedy). May cause fluctuations in network load and result in congestion collapse. How to protect your protocol against non-TCP friendly greedy protocols? RED is designed to solve this problem to some extent.

TCP friendly congestion control(3/3) Average rate same as TCP travelling along same data-path (rate computed via equation), but CM protocol has less rate variance. TCP Avg Rate TCP-friendly CM protocol

Classification of Congestion Control Schemes Window-Based vs. Rate-Based Unicast vs. Multicast Single-Rate vs. Multi-Rate End-to-End vs. Router-Supported

Window-Based vs. Rate-Based Window-Based Algorithms that belong to the window-based category use a congestion window at the sender or at the receiver(s) to ensure TCP friendliness. Rate-Based Rate-based congestion control achieves TCP friendliness by dynamically adapting the transmission rate according to some network feedback mechanism that indicates congestion. Ex. Simple AIMD schemes mimic the behavior of TCP congestion control.

Unicast vs. Multicast(1/3) The design of good multicast congestion control protocols is far more difficult than the design of unicast protocols. Multicast congestion control schemes ideally should scale to large receiver sets and be able to cope with heterogeneous network conditions at the receivers. For example, if for all receivers the sender transmits packets at the same rate, care has to be taken as to how the sending rate is decreased in case of network congestion.

Unicast vs. Multicast(2/3) Since in large multicast sessions receivers may experience uncorrelated loss. It is therefore likely that most of the transmitted packets are lost to at least one receiver. If the sender responded to each of these losses by decreasing the congestion window, the transmission would likely stall after a certain length of time. This problem is known as the loss path multiplicity problem [5].

Unicast vs. Multicast(3/3) They[6] show that window-based congestion control can be TCP-friendly without knowing the RTT, whereas rate-based congestion control does need this information in order to be TCP-friendly. This is an important insight, since RTTs are difficult to obtain in a scalable fashion for multicast communication without support from the network.

Single-Rate vs. Multi-Rate(1/2) A common criterion for classifying TCP-friendly multicast congestion control protocols is whether they operate at a single rate or use a multirate approach. unicast transport protocols are confined to single-rate schemes.

Single-Rate vs. Multi-Rate(2/2) Single-Rate Data is sent to all receivers at the same rate. This limits the scalability of the mechanism, since all receivers are restricted to the rate that is TCP-friendly for the bottleneck receiver. Multi-Rate Allow for a more flexible allocation of bandwidth along the different network paths. A sender divides the data into several layers and transmits them to different multicast groups. Each receiver can individually select to join as many groups as permitted by the bandwidth bottleneck between that receiver and the sender.

Multi-rate Congestion control Use layered multicast A sender divides the data into several layers and transmits them to different multicast groups. Each receiver can individually select to join as many groups as permitted by the bandwidth bottleneck between that receiver and the sender. Congestion control is performed indirectly by the group management and routing mechanisms of the underlying multicast protocol.

End-to-End vs. Router-Supported(1/7) End-to-End Many of the TCP-friendly schemes proposed are designed for best effort IP networks that do not provide any additional router mechanisms to support the protocols. Thus, they can readily be deployed in today ’ s Internet. Separated into sender-based and receiver-based approaches.

End-to-End vs. Router-Supported(2/7) Sender-based approaches The sender uses information about the network congestion and adjusts the rate or window size to achieve TCP friendliness. Receiver-based approaches The receivers only provide feedback, while the responsibility of adjusting the rate lies solely with the sender.

End-to-End vs. Router-Supported(3/7) router-supported Congestion control schemes that rely on additional functionality in the network. The design of congestion control protocols and particularly fair sharing of resources can be considerably facilitated by placing intelligence in the network (e.g., in routers or separate agents).

End-to-End vs. Router-Supported(4/7) router-supported Ex. Multicast protocols can benefit from additional network functionality such as feedback aggregation, hierarchical RTT measurements, management of (sub)groups of receivers, or modification of the routers ’ queuing strategies.

End-to-End vs. Router-Supported(5/7) Disadvantage End-to-End End-to-end congestion control has the disadvantage of relying on the collaboration of the end systems. Experience in the current Internet has shown that this cannot always be assumed: greedy users or applications may use non TCP-friendly mechanisms to gain more bandwidth. When a router discovers a flow which does not exhibit TCP-friendly behavior, the router might drop the packets of that flow with a higher probability than the packets of TCP-friendly flows.

End-to-End vs. Router-Supported(6/7) Disadvantage router-supported While ultimately fair sharing of resources in the presence of unresponsive or non-TCP-friendly flows can only be achieved with router support, this mechanism is difficult to deploy, since changes to the Internet infrastructure take time and are costly in terms of money and effort.

End-to-End vs. Router-Supported(7/7)

A classification scheme for TCP-friendly protocol

End-to-End, Rate-based, unicast protocol Rate Adaptation Protocol (RAP)

Rate Adaptation Protocol (RAP)(1/3) Goal: develop an end-to-end TCP-friendly RAP for semi-reliable rate-based applications (e.g. playback of real-time streams) RAP employs an additive-increase, multiplicative- decrease (AIMD) algorithm with implicit loss feedback to control congestion RAP separates congestion control from error control RAP is fair as long as TCP operates in a predictable AIMD mode Fine-grain rate adaptation extends range of fairness RED enhances fairness between TCP and RAP traffic RAP does not exhibit inherent instability

RAP Architecture RAP in a typical end-to-end architecture for realtime playback applications in the Internet

Rate Adaptation Protocol (RAP)(2/3) RAP is implemented at source host Each ACK packet contains sequence number of corresponding delivered data packet From ACKs, RAP source can detect losses and sample RTT Decision Function: if no congestion detected, periodically increase rate if congestion detected, immediately decrease rate Congestion detected through timeouts, and gaps in sequence space Timeout calculated based on Jacobson/Karel algorithm using RTT estimate (SRTT)

Decision Function RAP couples timer-based loss detection to packet transmission - before sending a new packet, source checks for a potential timeout among outstanding packets using most recent SRTT A packet is considered lost if an ACK implies delivery of 3 packets after the missing one (cf. fast recovery) RAP provides robustness against ACK losses by adding redundancy to ACK packets

Increase/Decrease Algorithm In absence of packet loss, increase rate additively in a step-like fashion Upon detecting congestion, decrease rate multiplicatively Rate controlled by adjusting inter- packet gap (IPG)

Decision Frequency RAP adjusts IPG once every SRTT If rate is increased by one packet, then slope of rate is inversely related to the square of SRTT (cf. linear increase of TCP) RAP emulates the coarse-grain rate adjustment of TCP RAP is unfair to flows with longer RTT as TCP

Rate Adaptation Protocol (RAP)(3/3) Time Rate Decision Freq Decision Function Increase Decrease Algorithm

Clustered Losses Right after loss of first packet, loss of following outstanding packets are silently ignored (cf. TCP-SACK) Cluster-loss-mode terminated as soon as ACK for a packet after that cluster is received

Fine-Grain Rate Adaption Goal: make RAP more stable and responsive to transient congestion Emulate a degree of congestion avoidance that TCP obtains due to ack- clocking (self-limiting) During a given step, multiply IPG by ratio of short-term average RTT to long-term average RTT

End-to-End, Rate-based, Multicast protocol Receiver-driven Layered Congestion Control (RLC)

Multicast for Content Delivery Pro: one copy of packet per link -- saves bandwidth Cons: challenges of reliability and congestion control, especially as session size scales Sender Receivers

Receiver-driven Layered Multicast (RLM) Code source in layers (base, enh1, enh2, … ) Send each layer to different multicast group Base layer... to multicast group G0 Enh. layer 1... to multicast group G1 Enh. layer 2... to multicast group G2 time S0 t S0 t+1 S0 t+2 S0 t+3 S0 t+4 S0 t+5 S1 t S1 t+1 S1 t+2 S1 t+3 S1 t+4 S1 t+5 S2 t S2 t+1 S2 t+2 S2 t+3 S2 t+4 S2 t+5 Receivers subscribe to as many layers as desired

Dynamic Joining/Leaving Receivers subscribe and unsubscribe according to instantaneous capacity S RR RR R

Layered Multicast Basic Ideas Set of multicast groups for each session with geometrically increasing rates (1, 1, 2, 4, 8, 16,..). Receivers adjust reception rate by joining and leaving multicast groups in cumulative order. Challenges how to ensure TCP-friendliness? how to coordinate receivers behind a bottleneck? only works when content encoding tolerates rate- adaptation (layered video coding).

Receiver-driven Layered Congestion Control (RLC)(1/5) RLC calls for synchronized join experiments, where the sender temporarily increases the sending rate on a layer Receiver will join a higher layer only if there is no packet loss during this experiment Convergence time is much shorter due to mimic the behavior of TCP congestion control It may cause the feedback implosion

Receiver-driven Layered Congestion Control (RLC)(2/5) Congestion control is achieved using SP ’ s. Burst of data sent right before SP. Receivers make join attempts only after a SP. Allows new users to quickly ramp up by placing SP ’ s conveniently. BW doubles with every higher layer and number of SP ’ s decrease with every higher layer. Synchronizes receivers.

Receiver-driven Layered Congestion Control (RLC)(3/5) 0 Time 1234 Aggregate rate Base layer Layer 1 Layer 2 Increase signal = 1 Increase signal = 2

Receiver-driven Layered Congestion Control (RLC)(4/5) Sender places increase signals in packets. Cumulative increase signals; signal j applies to all layers up through j. Frequency of increase signals inversely proportional to layer rate. Receiver measures loss, observes increase signals, and adjusts reception rate accordingly: Leave highest layer if loss. Join the next highest layer at an increase signal if no loss.

Receiver-driven Layered Congestion Control (RLC)(5/5) Coarse-grained approximation to additive increase. “ TCP-like ” in simulation. Early analysis/notions of TCP-friendliness. Adverse network impacts in practice: Doubling causes abrupt rate increases. Large buffer overflows; bursts of dropped packets.

References [1]S. Floyd and K. Fall, “ Promoting the Use of End-to-end Congestion Control in the Internet, ” IEEE/ACM Trans. Net., vol. 7, no. 4, Aug. 1999, pp. 458 – 72. [2] J. Padhye et al., “ Modeling TCP Reno Performance: A Simple Model and Its Empirical Validation, ” IEEE/ACM Trans. Net., vol. 8, no. 2, Apr. 2000, pp. 133 – 45. [3] H. A. Wang and M. Schwartz, “ Achieving Bounded Fairness for Multicast and TCP Traffic in the Internet, ” Proc. ACM SIGCOMM, [4] M. Vojnovic, J. Y. Le Boudec, and C. Boutremans, “ Global Fairness of Additive- Increase and Multiplicative-Decrease with Heterogeneous Round-Trip Times, ” Proc. IEEEa INFOCOM 2000, Tel Aviv, Israel, Mar [5] S. Bhattacharyya, D. Towsley, and J. Kurose, “ The Loss Path Multiplicity Problem in Multicast Congestion Control, ” Proc. IEEE INFOCOM, New York, NY, Mar. 1999, vol. 2, pp. 856 – 63. [6] S. J. Golestani and K. K. Sabnani, “ Fundamental Observations on Multicast Congestion Control in the Internet, ” Proc. INFOCOM ’ 99, Mar. 1999, vol. 2, pp. 990 – [7] B. Cain, T. Speakman, and D. Towsley, “ Generic Router Assist GRA Building Block Motivation and Architecture, ” Internet draft draft-ietf-rmt-gra-arch- 01.txt, Mar. 2000, work in progress. [8] J. Widmer, R. Denda, and M. Mauve, “ A Survey on TCP-Friendly Congestion Control (Extended Version), ” Tech. rep. TR , Dept. of Math. andComp. Sci., Univ. of Mannheim, Feb

[9] S. Jacobs and A. Eleftheriadis, “ Providing Video Services over Networks Without Quality of Service Guarantees, ” W3C Wksp. Real-Time Multimedia and the Web, Oct [10] R. Rejaie, M. Handley, and D. Estrin, “ Rap: An End-to-End Rate-Based Congestion Control Mechanism for Realtime Streams in the Internet, ” Proc. IEEE INFOCOM, Mar [11] D. Sisalem and A. Wolisz, “ LDA+ TCP-friendly adaptation: A Measurement and Comparison Study, ” Proc. Int ’ l. Wkshp. Network and Op. Sys. Support for Digital Audio and Video, June [12] H. Schulzrinne et al., “ Rtp: A Transport Protocol for Real-time Applications, ” RFC 1889, Jan [13] S. Floyd et al., “ Equation-based Congestion Control for Unicast Applications, ” Proc. ACM SIGCOMM, Stockholm, Sweden, Aug. 2000, pp. 43 – 56. [14] J. Padhye, D. Kurose, and R. Towsley, “ A model based TCP-friendly rate control protocol, ” Proc. Int ’ l. Wksp. Network and Op. Sys. Support for Digital Audio and Video, June [15] I. Rhee, V. Ozdemir, and Y. Yi, “ TEAR: TCP Emulation at Receivers – Flow Control for Multimedia Streaming, ” Tech. rep., Dept. of Comp. Sci., NCSU, Apr [16] S. Bhattacharyya, D. Towsley, and J. Kurose, “ A Novel Loss Indication Filtering Approach for Multicast Congestion Control, ” J. Comp. Commun., Special Issue on Multicast, [17] I. Rhee, N. Balaguru, and G. Rouskas, “ MTCP: Scalable TCP-Like Congestion Control for Reliable Multicast, ” Proc. IEEE INFOCOM, Mar. 1999, vol. 3, pp – 73. [18] S. Kasera et al., “ Scalable Fair Reliable Mulitcast Using Active Services, ” IEEE Net. (Special Issue on Multicast), vol. 14, no. 1, Jan./Feb. 2000, pp. 48 – 57.

[19] L. Rizzo, “ Pgmcc: A TCP-friendly single-rate Multicast Congestion Control Scheme, ” Proc. ACM SIGCOMM, Stockholm, Sweden, Aug. 2000, pp. 17 – 28. [20] S. McCanne, V. Jacobson, and M. Vetterli, “ Receiver-driven Layered Multicast, ” Proc. ACM SIGCOMM, Palo Alto, CA, Aug. 1996, pp. 117 – 30. [21] L. Vicisano, J. Crowcroft, and L. Rizzo, “ TCP-like Congestion Control for Layered Multicast Data Transfer, ” Proc. IEEE INFOCOM, Mar. 1998, vol. 3, pp. 996 – [22] J. Byers et al., “ FLID-DL: Congestion Control for Layered Multicast, ” Proc. 2nd Int ’ l Wkshp. Networked Group Commun., Palo Alto, CA, Nov [23] J. Byers et al., “ A Digital Fountain Approach to Reliable Distribution of Bulk Data, ” Proc. ACM SIGCOMM ‘ 98, Sept [24] T. Turletti, S. Parisis, and J. Bolot, “ Experiments with a Layered Transmission Scheme over the Internet, ” Tech. rep. RR-3296, INRIA, France, Nov [25] W. Tan and A. Zakhor, “ Error Control for Video Multicast Using Hierarchical FEC, ” Proc. Int ’ l. Conf. Image Processing, Oct [26] D. Sisalem and A. Wolisz, “ MLDA: A TCP-friendly Congestion Control Framework for Heterogenous Multicast Environments, ” 8th Int ’ l. Wksp. QoS, June [27] K. Yano and S. McCanne, “ A Window-based Congestion Control for Reliable Multicast Based on TCP Dynamics, ” Proc. ACM Multimedia, Oct [28] D. Estrin et al., “ Protocol Independent Multicast Sparse-mode (pimsm): Protocol Specification, ” IETF, RFC 2362, June [29] S. Savage et al., “ TCP Congestion Control with a Misbehaving Receiver, ” ACM Comp. Commun. Rev., vol. 29, no. 5, Oct. 1999, pp. 71 – 78.

END