A Survey on TCP-Friendly Congestion Control
童曉儒 教授 國立屏東科技大學 資管系
OutlineIntroductionTCP and TCP FriendlinessClassification of Congestion Control Schemes
Window-Based vs. Rate-BasedUnicast vs. MulticastSingle-Rate vs. Multi-RateEnd-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 applicationsHypertext Transfer Protocol (HTTP)Simple Mail Transfer Protocol (SMTP)File Transfer Protocol (FTP)
Introduction(2/4)Non-TCP traffic applications is constantly growing.
Internet audio playersIP telephonyVideoconferencingreal-time applications
Upon encountering congestionAll 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 mechanismassumes that end systems correctly follow the protocol
Coexistence of TCP flow and non-TCP flow (or faked TCP flow)
If one is greedy unfairnessIf 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 networkWhy is it a problem?
Sources are not aware of current state of resourcesSources are not aware of each otherIn many situations will result in < 1.5 Mbps throughput (congestion collapse)
10 Mb/s
100 Mb/s
1.5 Mb/s
RTT and RTOA B
ACK
SampleRTT
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)
8 Kbytes
16 Kbytes
24 Kbytes
time
congestionwindow
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 WIncrease parameter a, Decrease parameter b
Each RTT increase window to W+aUpon loss event decrease to (1-b)WTCP uses AIMD(1, ½)
Increase by 1 every RTTDecrease 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
21R
3
42R
567
83R
91011
1213
1415
1
2 3
4 5 6 7
Example assumes that acks are not delayed
0
2
4
6
8
10
12
14
0 1 2 3 4 5 6 7 8
Time (round trips)
Con
gest
ion
Win
dow
size
(seg
men
ts)
Slow start
Congestionavoidance
Slow start threshold
Congestion Control -- Timeout
0
5
10
15
20
25
0 3 6 9 12 15 20 22 25
Time (round trips)
Con
gest
ion
win
dow
(se
gmen
ts)
ssthresh = 8 ssthresh = 10
cwnd = 20
After timeout
TCP Saw Tooth Behavior
Time
CongestionWindow
InitialSlowstart
Fast Retransmit
and Recovery
Slowstartto pacepackets
Timeoutsmay still
occur
TCP’s Rate Control
[Reno, NewReno]
time
congestion windowsize (cwnd)
limit
ssthresh
AIMD
slow startphase
AdditiveMultiplicative
congestion avoidancephase
TCP Window Flow Control
acknowledged sent to be sent outside window
Source PortSource Port Dest. PortDest. Port
Sequence NumberSequence Number
AcknowledgmentAcknowledgment
HL/FlagsHL/Flags WindowWindow
D. ChecksumD. Checksum Urgent PointerUrgent Pointer
Options..Options..
Source PortSource Port Dest. PortDest. Port
Sequence NumberSequence Number
AcknowledgmentAcknowledgment
HL/FlagsHL/Flags WindowWindow
D. ChecksumD. Checksum Urgent PointerUrgent Pointer
Options..Options..
Packet Sent Packet Received
App write
Sliding Window Flow ControlSliding Window Protocol is performed at the byte level:
1 2 3 4 5 6 7 8 9 10 11
Advertised window
sent but notacknowledged can be sent
USABLEWINDOW
sent andacknowledged
can't sent
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
bottleneckrouter
capacity R
TCP connection 2
TCP FriendlinessTCP 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.
ThroughputThe effect of a non-TCP flow on competing TCP flows rather than on the throughput of the non-TCP flow.
TCP-Friendly FlowsUnresponsive 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 TCPBacks 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-BasedWindow-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-BasedRate-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-RateAllow 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 controlUse 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-EndMany 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 approachesThe sender uses information about the network congestion and adjusts the rate or window size to achieve TCP friendliness.
Receiver-based approachesThe 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-supportedCongestion 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-supportedEx. 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)
DisadvantageEnd-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 congestionRAP separates congestion control from error controlRAP is fair as long as TCP operates in a predictable AIMD mode Fine-grain rate adaptation extends range of fairnessRED enhances fairness between TCP and RAP trafficRAP 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 hostEach ACK packet contains sequence number of corresponding delivered data packetFrom ACKs, RAP source can detect losses and sample RTTDecision Function:
if no congestion detected, periodically increase rate if congestion detected, immediately decrease rate
Congestion detected through timeouts, and gaps in sequence spaceTimeout 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 SRTTA 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 fashionUpon detecting congestion, decrease rate multiplicativelyRate controlled by adjusting inter-packet gap (IPG)
Decision Frequency
RAP adjusts IPG once every SRTTIf 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 TCPRAP 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 congestionEmulate 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 bandwidthCons: 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
S0t S0t+1 S0t+2 S0t+3 S0t+4 S0t+5
S1t S1t+1 S1t+2 S1t+3 S1t+4 S1t+5
S2t S2t+1 S2t+2 S2t+3 S2t+4 S2t+5
Receivers subscribe to as many layers as desired
Dynamic Joining/Leaving
Receivers subscribe and unsubscribe according to instantaneous capacity
S
RR
RRR
Layered MulticastBasic 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.
Challengeshow 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 experimentConvergence time is much shorter due to mimic the behavior of TCP congestion controlIt 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
1 2 3 4
Aggregaterate
0
1
5 6
2
3
4
5
6
Base layer
Layer 1
Layer 2
Increasesignal = 1
Increasesignal = 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, 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.
[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.
[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