a survey on tcp-friendly congestion control 童曉儒教授國立屏東科技大學資管系

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


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


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


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.


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.


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.


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


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.


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.

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


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


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


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.


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


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.


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.

a survey on tcp-friendly congestion control 童曉儒 教授 國立屏東科技大學 資管系

Documents

a survey on tcp-friendly congestion control 童曉儒教授國立屏東科技大學資管系