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

3. Outline Introduction Congestion User datagram protocol (UDP) Transmission Control Protocol (TCP) TCP Friendliness Rate Adaptation Protocol (RAP) Conclusions

4. 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)

5. 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.

6. 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

7. 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.

8. 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

9. 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

10. User datagram protocol (UDP) UDP is another transport protocol in the TCP/IP suite UDP provides an unreliable datagram service  Packets may be lost or delivered out of order  Users exchange datagrams (not streams)  Connection-less  Not buffered -- UDP accepts data and transmits immediately (no buffering before transmission)  Full duplex -- concurrent transfers can take place in both directions

11. User datagram protocol (UDP) source port destination port message lengthchecksum data

12. User datagram protocol (UDP) UDP Destination Port: identifies destination process UDP Source Port: optional – identifies source process for replies, or zero Message Length: length of datagram in bytes, including header and data Checksum: optional -- 16-bit checksum over header and data, or zero

13. UDP Versus TCP (1) Choice of UDP versus TCP is based on:  Functionality  Performance Performance  TCP’s window-based flow control scheme leads to bursty bulk transfers (not rate based)  TCP’s “slow start” algorithm can reduce throughput  TCP has extra overhead per segment  UDP can send small, inefficient datagrams

14. UDP Versus TCP (2) Reliability  TCP provides reliable, in-order transfers  UDP provides unreliable service – application must accept or deal with Packet loss due to overflows and errors Out-of-order datagrams Multicast and broadcast  Supported only by UDP  TCP’s error control scheme does not lend itself to reliable multicast Data size  UDP datagrams limited to IP MTU (64KB)

15. UDP Versus TCP (3) Application complexity  Application-level framing can be difficult using TCP because of the Nagle algorithm  Nagle algorithm controls when TCP segments are sent to use IP datagrams efficiently  But, data may be received and read by applications in different units than how it was sent

16. UDP versus TCP (4)  HyperText Transfer Protocol (HTTP)  File Transfer Protocol (FTP)  Telnet  Post Office Protocol (POP)  MBONE audio/video  Real Player  Network File System (NFS)

17. Transmission Control Protocol (TCP) End-to-end transport protocol Responsible for reliability, congestion control, flow control, and sequenced delivery Applications that use TCP: http (web), telnet, ftp (file transfer), smtp (email), chat Applications that don’t: multimedia (typically) – use UDP instead

18. Transmission Control Protocol (TCP)

19. Source port Destination port Sequence number Acknowlegement number Data offsetReservedFlagsWindow ChecksumUrgent pointer Options(+padding) Date (variable)

20. Transmission Control Protocol (TCP) Each connection identified with 4-tuple:  (SrcPort, SrcIPAddr, DsrPort, DstIPAddr) Sliding window + flow control  acknowledgment, SequenceNum, AdvertisedWinow Flags  SYN, FIN, RESET, PUSH, URG, ACK Checksum is the same as UDP  pseudo header + TCP header + data Sender Data(SequenceNum) Acknowledgment + AdvertisedWindow Receiver

21. Transmission Control Protocol (TCP)

24. TCP Congestion control  Slow-Start  Congestion Avoidance (AIMD)  Retransmission

25. Transmission Control Protocol (TCP)

26. TCP slow-start 1 One RTT One pkt time 0R 2 1R 3 4 2R 5 6 7 8 3R 9 10 11 12 13 14 15 1 23 4567

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

28. 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

29. 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.

30. 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.

31. 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.

32. 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

33. TCP-friendly protocol

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

35. 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 RED enhances fairness between TCP and RAP traffic

36. Rate Adaptation Protocol (RAP) 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

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

38. Rate Adaptation Protocol (RAP) Decision Function Increase/decrease Algorithm Decision Frequency

39. Decision Function  If no congestion is detected, periodically increase the transmission rate  If congestion is detected, immediately decrease the transmission rate.  Congestion detected through timeouts, and gaps in sequence space  Timeout calculated based on Jacobson/Karel algorithm using RTT estimate (called SRTT)

40. Increase/decrease Algorithm RAP uses an AIMD increase/decrease algorithm. The transmission rate is controlled by adjusting the inter-packet-gap (IPG). To increase the rate additively, IPG must be iteratively updated based on equation (1) Si → transmission rate α → step height C → is a constant with the dimension of time

41. Inter-Packet-Gap (IPG). Interval represents the time between the arrival of the previous packet and arrival of the current packet. The arrival time corresponds to the reception of the last bit of a packet. For example, if PcktSize = 100 and Interval = 250, then the inter- packet gap is 250-100 = 150 bytes. inter-packet gap

42. Increase/decrease Algorithm Upon detecting congestion, the transmission rate is decreased multiplicatively, by doubling the value of IPG:

43. Decision Frequency Decision frequency specifies how often to change the rate. The optimal adjustment frequency depends on the feedback delay. It is suggested that rate-based schemes adjust their rates not more than once per RIT Changing the rate too often results in oscillation whereas infrequent change leads to unresponsive behavior.

44. Decision Frequency RAP adjusts the IPG once every SRTT using (1). The time between two subsequent adjustment points is called a step. If no loss is detected, IPG is decreased and a new step is started.

45. Decision Frequency rate 1 2 3 4 5 6 7 8 (SRTT)

47. 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, 1998. [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. 2000. [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–1000. [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-2001-002, Dept. of Math. andComp. Sci., Univ. of Mannheim, Feb. 2001.

48. References [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. 1996. [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. 1999. [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 2000. [12] H. Schulzrinne et al., “Rtp: A Transport Protocol for Real-time Applications,” RFC 1889, Jan. 1996. [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 1999. [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. 2000. [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, 2000. [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. 1265–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.

49. References [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–1003. [22] J. Byers et al., “FLID-DL: Congestion Control for Layered Multicast,” Proc. 2nd Int’l Wkshp. Networked Group Commun., Palo Alto, CA, Nov. 2000. [23] J. Byers et al., “A Digital Fountain Approach to Reliable Distribution of Bulk Data,” Proc. ACM SIGCOMM ‘98, Sept. 1998. [24] T. Turletti, S. Parisis, and J. Bolot, “Experiments with a Layered Transmission Scheme over the Internet,” Tech. rep. RR-3296, INRIA, France, Nov. 1997. [25] W. Tan and A. Zakhor, “Error Control for Video Multicast Using Hierarchical FEC,” Proc. Int’l. Conf. Image Processing, Oct. 1999. [26] D. Sisalem and A. Wolisz, “MLDA: A TCP-friendly Congestion Control Framework for Heterogenous Multicast Environments,” 8th Int’l. Wksp. QoS, June 2000. [27] K. Yano and S. McCanne, “A Window-based Congestion Control for Reliable Multicast Based on TCP Dynamics,” Proc. ACM Multimedia, Oct. 2000. [28] D. Estrin et al., “Protocol Independent Multicast Sparse-mode (pimsm): Protocol Specification,” IETF, RFC 2362, June 1998. [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.

50. END