TCP-Friendly Congestion Control

童曉儒 教授 國立屏東科技大學 資管系

Outline

Introduction Congestion User datagram protocol (UDP) Transmission Control Protocol (TCP) TCP Friendliness Rate Adaptation Protocol (RAP) 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

User datagram protocol (UDP) UDP is another transport protocol in the TCP/IP s

uite 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 immedi

ately (no buffering before transmission) Full duplex -- concurrent transfers can take place in bot

h directions

User datagram protocol (UDP)

source port destination port

message length checksum

data

User datagram protocol (UDP) UDP Destination Port: identifies destination proce

ss UDP Source Port: optional – identifies source pro

cess for replies, or zero Message Length: length of datagram in bytes, incl

uding header and data Checksum: optional -- 16-bit checksum over head

er and data, or zero

UDP Versus TCP (1)

Choice of UDP versus TCP is based on: Functionality Performance

Performance TCP’s window-based flow control scheme leads to bur

sty 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

UDP Versus TCP (2)

Reliability TCP provides reliable, in-order transfers UDP provides unreliable service – application must accept or dea

l 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 multic

ast Data size

UDP datagrams limited to IP MTU (64KB)

UDP Versus TCP (3)

Application complexity Application-level framing can be difficult using TCP b

ecause 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 d

ifferent units than how it was sent

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)

Transmission Control Protocol (TCP)

End-to-end transport protocol Responsible for reliability, congestion control, flo

w control, and sequenced delivery Applications that use TCP: http (web), telnet, ftp

(file transfer), smtp (email), chat Applications that don’t: multimedia (typically) – u

se UDP instead

Transmission Control Protocol (TCP)

Transmission Control Protocol (TCP)

Source port 　 　 Destination port 　　 Sequence number

Acknowlegement number

Data offset Reserved Flags Window

Checksum Urgent pointer

Options(+padding)

Date (variable)

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

Transmission Control Protocol (TCP)

Transmission Control Protocol (TCP)

Transmission Control Protocol (TCP)

Transmission Control Protocol (TCP)

TCP Congestion control Slow-Start Congestion Avoidance (AIMD) Retransmission

Transmission Control Protocol (TCP)

TCP slow-start

1

One RTT

One pkt time

0R

21R

3

42R

567

83R

91011

1213

1415

1

2 3

4 5 6 7

TCP Saw Tooth Behavior

Time

CongestionWindow

InitialSlowstart

Fast Retransmit

and Recovery

Slowstartto pacepackets

Timeoutsmay still

occur

TCP Fairness

Fairness goal If K TCP sessions share same bottleneck link of bandw

idth R, each should have average rate of R/K

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2

TCP Friendliness

TCP Friendliness 「 their long-term throughput does not exceed the thro

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

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 d

ata-path (rate computed via equation), but CM protocol has less rate variance.

TCP

Avg Rate

TCP-friendly CM protocol

TCP-friendly protocol

End-to-End , Rate-based , unicast protocol

Rate Adaptation Protocol (RAP)

Rate Adaptation Protocol (RAP)

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

Rate Adaptation Protocol (RAP)

RAP is implemented at source host Each ACK packet contains sequence number of correspon

ding delivered data packet From ACKs, RAP source can detect losses and sample R

TT Decision Function: if no congestion detected, periodically increase rate if congestion detected, immediately decrease rate

RAP Architecture

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

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

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)

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 e

quation (1)

Si → transmission rate

α → step height

C → is a constant with the dimension of time

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

Increase/decrease Algorithm

Upon detecting congestion, the transmission rate is decreased multiplicatively, by doubling the value of IPG:

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.

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.

Decision Frequency

rate

1 2 3 4 5 6 7 8 (SRTT)

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.

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 St

reaming,” Tech. rep., Dept. of Comp. Sci., NCSU, Apr. 2000. [16] S. Bhattacharyya, D. Towsley, and J. Kurose, “A Novel Loss Indication Filtering Approach for Multica

st 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 M

ulticast,” 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.

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.

END