USF Libraries
USF Digital Collections

SF-SACK

MISSING IMAGE

Material Information

Title:
SF-SACK a smooth friendly TCP protocol for streaming multimedia applications
Physical Description:
Book
Language:
English
Creator:
Bakthavachalu, Sivakumar
Publisher:
University of South Florida
Place of Publication:
Tampa, Fla.
Publication Date:

Subjects

Subjects / Keywords:
TCP-friendly
Fairness index
Streaming video
Transport layer
Congestion control
RCP/IP
Dissertations, Academic -- Computer Science -- Masters -- USF   ( lcsh )
Genre:
government publication (state, provincial, terriorial, dependent)   ( marcgt )
bibliography   ( marcgt )
theses   ( marcgt )
non-fiction   ( marcgt )

Notes

Summary:
ABSTRACT: Voice over IP and video applications continue to increase the amount of traffic over the Internet. These applications utilize the UDP protocol because TCP is not suitable for streaming applications. The flow and congestion control mechanisms of TCP can change the connection transmission rate too drastically, affecting the user-perceived quality of the transmission. Also, the TCP protocol provides a level of reliability that may waste network resources, retransmitting packets that have no value. On the other hand, the use of end-to-end flow and congestion control mechanisms for streaming applications has been acknowledged as an important measure to ease or eliminate the unfairness problem that exist when TCP and UDP share the same congested bottleneck link. Actually, router-based and end-to-end solutions have been proposed to solve this problem.This thesis introduces a new end-to-end protocol based on TCP SACK called SF-SACK that promises to be smooth enough for streaming applications while implementing the known flow and congestion control mechanisms available in TCP. Through simulations, it is shown that in terms of smoothness the SF-SACK protocol is considerably better than TCP SACK and only slightly worse than TFRC. Regarding friendliness, SF-SACK is not completely fair to TCP but considerably fairer than UDP. Furthermore, if SF-SACK is used by both streaming and data-oriented applications, complete fairness is achieved. In addition, SF-SACK only needs sender side modifcations and it is simpler than TFRC.
Thesis:
Thesis (M.S.C.S.)--University of South Florida, 2004.
Bibliography:
Includes bibliographical references.
System Details:
System requirements: World Wide Web browser and PDF reader.
System Details:
Mode of access: World Wide Web.
Statement of Responsibility:
by Sivakumar Bakthavachalu.
General Note:
Title from PDF of title page.
General Note:
Document formatted into pages; contains 71 pages.

Record Information

Source Institution:
University of South Florida Library
Holding Location:
University of South Florida
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
aleph - 001680993
oclc - 62500112
usfldc doi - E14-SFE0000608
usfldc handle - e14.608
System ID:
SFS0025298:00001


This item is only available as the following downloads:


Full Text
xml version 1.0 encoding UTF-8 standalone no
record xmlns http:www.loc.govMARC21slim xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.loc.govstandardsmarcxmlschemaMARC21slim.xsd
leader nam Ka
controlfield tag 001 001680993
003 fts
005 20060215071102.0
006 m||||e|||d||||||||
007 cr mnu|||uuuuu
008 051207s2004 flu sbm s000 0 eng d
datafield ind1 8 ind2 024
subfield code a E14-SFE0000608
035
(OCoLC)62500112
SFE0000608
040
FHM
c FHM
049
FHMM
090
2004
1 100
Bakthavachalu, Sivakumar.
0 245
SF-SACK
h [electronic resource] :
b a smooth friendly TCP protocol for streaming multimedia applications /
by Sivakumar Bakthavachalu.
260
[Tampa, Fla.] :
University of South Florida,
2004.
502
Thesis (M.S.C.S.)--University of South Florida, 2004.
504
Includes bibliographical references.
516
Text (Electronic thesis) in PDF format.
538
System requirements: World Wide Web browser and PDF reader.
Mode of access: World Wide Web.
500
Title from PDF of title page.
Document formatted into pages; contains 71 pages.
520
ABSTRACT: Voice over IP and video applications continue to increase the amount of traffic over the Internet. These applications utilize the UDP protocol because TCP is not suitable for streaming applications. The flow and congestion control mechanisms of TCP can change the connection transmission rate too drastically, affecting the user-perceived quality of the transmission. Also, the TCP protocol provides a level of reliability that may waste network resources, retransmitting packets that have no value. On the other hand, the use of end-to-end flow and congestion control mechanisms for streaming applications has been acknowledged as an important measure to ease or eliminate the unfairness problem that exist when TCP and UDP share the same congested bottleneck link. Actually, router-based and end-to-end solutions have been proposed to solve this problem.This thesis introduces a new end-to-end protocol based on TCP SACK called SF-SACK that promises to be smooth enough for streaming applications while implementing the known flow and congestion control mechanisms available in TCP. Through simulations, it is shown that in terms of smoothness the SF-SACK protocol is considerably better than TCP SACK and only slightly worse than TFRC. Regarding friendliness, SF-SACK is not completely fair to TCP but considerably fairer than UDP. Furthermore, if SF-SACK is used by both streaming and data-oriented applications, complete fairness is achieved. In addition, SF-SACK only needs sender side modifcations and it is simpler than TFRC.
590
Adviser: Labrador, Miguel A.
653
TCP-friendly.
Fairness index.
Streaming video.
Transport layer.
Congestion control.
RCP/IP.
690
Dissertations, Academic
z USF
x Computer Science
Masters.
773
t USF Electronic Theses and Dissertations.
4 856
u http://digital.lib.usf.edu/?e14.608



PAGE 1

SF-SA CK: A Smooth Friendly TCP Protocol for Streaming Multimedia Applications by Si v akumar Baktha v achalu A thesis submitted in partial fulllment of the requirements for the de gree of Master of Science in Computer Science Department of Computer Science and Engineering Colle ge of Engineering Uni v ersity of South Florida Major Professor: Miguel A. Labrador Ph.D. Srini v as Katk oori, Ph.D. N. Ranganathan, Ph.D. Date of Appro v al: April 16, 2004 K e yw ords: Congestion Control, TCP/IP TCP-Friendly F airness Inde x, Streaming V ideo, T ransport Layer cCop yright 2004, Si v akumar Baktha v achalu

PAGE 2

DEDICA TION T o my f amily and friends

PAGE 3

A CKNO WLEDGEMENTS I tak e this opportunity to thank my graduate advisor Dr Labrador who has gi v en me a chance to w ork with him in shaping this thesis under his guidance. He has been a constant encouragement throughout my research period and has se v eral times helped me in staying on with my thesis when things weren' t coming out as e xpected. He w as v ery much a v ailable to answer questions and discussions on the subject. I w ould also lik e to thank Dr Katk oori and Dr Ranganathan for their interest in this research and taking the time to re vie w this thesis. Special thanks to my colleague and graduate student, V enkatesh, for his moral support and technical help at crucial times of my research w ork. I denitely need to mention Sharath Reddy graduate student in EE, in e xplaining some electrical engineering concepts related to my thesis. I am sure just a mention is not enough for the encouragement and support of my great roommates, Madhan, Srinath and V enkatesh. I am v ery thankful to Alicia Balsera, Associate Director and my supervisor and friend, Glen P ark er at Academic Computing T echnologies, USF for their constant support to w ards my Masters de gree. Also thanks to all the Staf f and Student emplo yees at Academic Computing for gi ving me a w onderful e xperience. Finally thanks to my f amily and friends who ha v e al w ays been with me supporting my career goals.

PAGE 4

T ABLE OF CONTENTS LIST OF T ABLES iii LIST OF FIGURES i v ABSTRA CT vi CHAPTER 1 INTR ODUCTION 1 1.1 Background 1 1.2 Moti v ation 1 1.3 Contrib utions of This Thesis 3 1.4 Or ganization of This Document 3 CHAPTER 2 B A CKGR OUND AND LITERA TURE REVIEW 4 2.1 User Datagram Protocol (UDP) 4 2.2 T ransmission Control Protocol (TCP) 6 2.2.1 W indo w-Based Algorithms 7 2.2.2 Rate-Based Algorithms 11 2.2.2.1 TCP-Friendly Rate Control Protocol 11 CHAPTER 3 SF-SA CK: SMOO TH FRIENDL Y PR O T OCOL 14 3.1 Congestion W indo w Estimation 14 3.2 Lo w-P ass Filter 14 3.3 Explanation of The Algorithm 17 3.4 Finding Optimal Cut-Of f Frequenc y 19 3.5 K e y Features of the Ne w Algorithm 19 CHAPTER 4 SIMULA TION T OPOLOGY AND P ARAMETERS 20 4.1 Static Netw ork Scenario 20 4.1.1 Performance Metrics 22 4.2 Dynamic Netw ork Scenario 23 4.2.1 Performance Metrics 24 CHAPTER 5 PERFORMANCE EV ALU A TION OF TCP-FRIENDL Y RA TE CONTR OL PR O T OCOL 26 5.1 Static Netw ork Conditions 26 5.1.1 Normalized Throughput 26 5.1.2 Ef fect of Explicit Congestion Notication (ECN) 31 5.1.3 F airness of TFRC Protocol 34 5.2 Dynamic Netw ork Scenario 36 5.2.1 Long-T erm F airness of TFRC 36 i

PAGE 5

5.2.2 Short-T erm/T ransient F airness of TFRC 38 5.3 Conclusions on TFRC Protocol 39 CHAPTER 6 PERFORMANCE EV ALU A TION OF SF-SA CK PR O T OCOL 40 6.1 Optimal Cut-Of f Frequenc y () of Lo w-P ass Filter 40 6.2 Performance of SF-SA CK Under Static Netw ork Scenario 42 6.2.1 Congestion W indo w V ariation 42 6.2.2 Throughput Performance of SF-SA CK 45 6.2.3 TCP-Friendliness of SF-SA CK 49 6.2.4 Friendliness of TCP UDP and SF-SA CK Flo ws 53 6.2.5 F airness of SF-SA CK 55 6.3 Performance of SF-SA CK Under Dynamic Netw ork Scenario 56 6.3.1 Long-T erm F airness of SF-SA CK 56 6.3.2 Short-T erm F airness of SF-SA CK 57 CHAPTER 7 CONCLUSION AND FUTURE W ORK 59 REFERENCES 60 ii

PAGE 6

LIST OF T ABLES T able 4.1 P arameters and their V alues of the Dumbbell T opology 21 T able 4.2 RED Queue P arameters 22 T able 5.1 Mean Normalized Throughput and Standard De viation of TCP T ahoe When Competing W ith TFRC W ithout ECN and W ith (ECN) 29 T able 5.2 Mean Normalized Throughput and Standard De viation of TCP Reno When Competing W ith TFRC W ithout ECN and W ith (ECN) 29 T able 5.3 Mean Normalized Throughput and Standard De viation of TCP Ne w Reno When Competing W ith TFRC W ithout ECN and W ith (ECN) 29 T able 5.4 Mean Normalized Throughput and Standard De viation of TCP Sack When Competing W ith TFRC W ithout ECN and W ith (ECN) 30 T able 5.5 Mean Normalized Throughput and Standard De viation of TCP V egas When Competing W ith TFRC W ithout ECN and W ith (ECN) 30 T able 5.6 Mean Normalized Throughput and Standard De viation of GAIMD When Competing W ith TFRC W ithout ECN and W ith (ECN) 30 T able 5.7 Mean Normalized Throughput and Standard De viation of SQR T Binomial When Competing W ith TFRC W ithout ECN and W ith (ECN) 30 T able 5.8 Mean Normalized Throughput and Standard De viation of IIAD Binomial When Competing W ith TFRC W ithout ECN and W ith (ECN) 31 T able 5.9 F ormulas Corresponding to The Increase and Decrease Beha vior of cwnd of TCP GAIMD, SQR T and IIAD 32 T able 5.10 Con v er gence T imes (In Seconds) of V arious Protocols W ith and W ithout ECN 38 T able 6.1 Mean, Standard De viation, and Co-ef cient of V ariation of Throughput V alues for V arious Competing TCP Protocols at 60 Mbps Bottleneck Bandwidth 47 T able 6.2 Mean, Standard De viation, and Co-ef cient of V ariation of Throughput V alues for V arious Competing TCP Protocols at 15 Mbps Bottleneck Bandwidth 47 T able 6.3 Con v er gence T imes (In Seconds) of SF-SA CK and Other Protocols 58 iii

PAGE 7

LIST OF FIGURES Figure 2.1 Cwnd Graph Sho wing Slo w Start, Congestion A v oidance and F ast Reco v ery Phases In TCP 9 Figure 3.1 Snapshot of Cwnd V ariation Sho wing the W orking of SF-SA CK Algorithm 17 Figure 4.1 The Dumbbell Simulation T opology for Static Netw ork Scenario 21 Figure 4.2 The Dumbbell Simulation T opology for Dynamic Netw ork Scenario Sho wing the ON/OFF Square-W a v e CBR Source 24 Figure 5.1 Normalized Throughput of TFRC Flo ws Competing W ith Other Protocols W ith RED and W ithout ECN 27 Figure 5.2 Normalized Throughput of TFRC Flo ws Competing W ith Other Protocols W ith RED and W ith ECN 33 Figure 5.3 F airness Inde x of Flo ws Competing W ith TFRC W ithout ECN 35 Figure 5.4 F airness Inde x of Flo ws Competing W ith TFRC W ith ECN 35 Figure 5.5 Long-T erm F airness of TFRC Flo ws and Competing Protocols Under Dynamic Netw ork Conditions W ith ECN 37 Figure 6.1 3D Graph Sho wing V ariation of cwnd W ith T ime for Dif ferent tau V alues Using 60 Mbps Bottleneck Link 41 Figure 6.2 3D Graph Sho wing V ariation of cwnd W ith T ime for Dif ferent tau V alues Using 15 Mbps Bottleneck Link 41 Figure 6.3 Congestion W indo w V ariation of T w o Flo ws of Same Class Competing for a 60 Mbps Bottleneck Bandwidth Link 43 Figure 6.4 Congestion W indo w V ariation of T w o Flo ws of Same Class Competing for a 15 Mbps Bottleneck Bandwidth Link 44 Figure 6.5 Throughput V ariation of T w o Flo ws of Same Class Competing for a 60 Mbps Bottleneck Bandwidth Link 46 Figure 6.6 Throughput V ariation of T w o Flo ws of Same Class Competing for a 15 Mbps Bottleneck Bandwidth Link 48 Figure 6.7 Normalized Throughput and Loss-Rates of SF-SA CK Flo ws Competing with other TCP V ersions on a 60 Mbps Bottleneck Bandwidth Link 49 i v

PAGE 8

Figure 6.8 Normalized Throughput and Loss-Rates of SF-SA CK Flo ws Competing with other TCP V ersions on a 15 Mbps Bottleneck Bandwidth Link 51 Figure 6.9 A v erage Throughput of a UDP Flo w Running CBR and A TCP Flo w Running FTP Application 53 Figure 6.10 A v erage Throughput of a TCP Flo w Running CBR and A TCP Flo w Running FTP Application 54 Figure 6.11 A v erage Throughput of T w o SF-SA CK Flo ws Each Running a CBR and an FTP Application 54 Figure 6.12 F airness Inde x of SF-SA CK Flo w Competing for 60 Mbps Bottleneck Link W ith Other TCP W indo w-Based Flo ws and TFRC 55 Figure 6.13 F airness Inde x of SF-SA CK Flo w Competing for 15 Mbps Bottleneck Link W ith Other TCP W indo w-Based Flo ws and TFRC 55 Figure 6.14 Long T erm F airness of SF-SA CK Flo ws Competing W ith Other TCP Protocols Under Dynamic Netw ork Scenario 57 v

PAGE 9

SF-SA CK: A SMOO TH FRIENDL Y TCP PR O T OCOL FOR STREAMING MUL TIMEDIA APPLICA TIONS Si v akumar Baktha v achalu ABSTRA CT V oice o v er IP and video applications continue to increase the amount of traf c o v er the Internet. These applications utilize the UDP protocol because TCP is not suitable for streaming applications. The o w and congestion control mechanisms of TCP can change the connection transmission rate too drastically af fecting the user -percei v ed quality of the transmission. Also, the TCP protocol pro vides a le v el of reliability that may w aste netw ork resources, retransmitting pack ets that ha v e no v alue. On the other hand, the use of end-to-end o w and congestion control mechanisms for streaming applications has been ackno wledged as an important measure to ease or eliminate the unf airness problem that e xist when TCP and UDP share the same congested bottleneck link. Actually router -based and end-to-end solutions ha v e been proposed to solv e this problem. This thesis introduces a ne w end-to-end protocol based on TCP SA CK called SF-SA CK that promises to be smooth enough for streaming applications while implementing the kno wn o w and congestion control mechanisms a v ailable in TCP Through simulations, it is sho wn that in terms of smoothness the SF-SA CK protocol is considerably better than TCP SA CK and only slightly w orse than TFRC. Re garding friendliness, SF-SA CK is not completely f air to TCP b ut considerably f airer than UDP Furthermore, if SF-SA CK is used by both streaming and data-oriented applications, complete f air ness is achie v ed. In addition, SF-SA CK only needs sender side modications and it is simpler than TFRC. vi

PAGE 10

CHAPTER 1 INTR ODUCTION 1.1 Backgr ound The stability of the Internet is attrib uted to the congestion control mechanisms implemented in the T ransmission Control Protocol (TCP), rst de v eloped by V an Jacobson [1] and deplo yed in the Internet in 1988. Ho we v er TCP is not v ery well suited for the emer ging streaming multimedia applications. TCP is not suited because of the reasons inherent to its congestion control mechanism, whereby TCP backs of f its transmission rate when congestion is detected in the netw ork. This reduces the user -percei v ed quality of the streaming audio/video due to delay and jitter and transmission losses. Hence to pro vide better streaming quality such applications started using the User Datagram Protocol (UDP) [2 ] which sends pack ets at a x ed rate re gardless of the state of the netw ork. Though UDP satises the requirements of streaming media applications in deli v ering a smoothed transfer it is an unreliable transport service and does not include o w and congestion control mechanisms. The UDP protocol has created tw o important problems. First, TCP and UDP does not w ork v ery well together when the y share common resources. In this case, UDP tak es all a v ailable resources at TCP' s e xpense. This is commonly kno wn as the TCP-Friendliness problem, rst reported in [3]. Second, UDP also created the problem of Congestion Collapse in the Internet whereby resources are consumed unnecessarily while pre v enting their usage by others. 1.2 Moti v ation The increase in multimedia traf c in the Internet has encouraged a number of researchers in proposing protocols pro viding smooth transmission rates while being TCP-F riendly In addition, since these protocols someho w react to netw ork congestion, the y also address the problem of congestion collapse. These solutions ha v e been de vised as router -based or end-to-end-based solutions depending on where the solution is implemented [4 ]. One recently proposed is the TCP-Friendly 1

PAGE 11

Rate Control (TFRC) Protocol [5 ], a protocol that based on the formula that characterizes the steady state beha vior of the TCP throughput, promises smoother transfer rates for streaming applications while being friendly to TCP Ho we v er despite the good performance of TFRC, it still poseses se veral problems and challenges. Among the most important ones are:TFRC needs to be further in v estigated to mak e sure it can be safely deplo yed in the Internet.TFRC is a Rate-based completely ne w protocol more dif cult to understand than TCP .TFRC requires dif ferent sender and recei v er since it relies on the recei v er to estimate the loss e v ent rate.The TCP throughput equation used by TFRC does not characterize the entire beha vior of TCP .TFRC needs to estimate se v eral parameters such as the pack et loss rate and pack et size which are not al w ays easy and/or accurate to estimate. The abo v e features of TFRC are the moti v ating f actors for the design of a ne w transport protocol for streaming applications. Moreo v er designing the ne w transport protocol using underlying re gular TCP enables us to deri v e the adv antages of the windo w-based congestion control mechanism. F or normal reliable transport, windo w-based solutions of fer a number of adv antages, some of which are listed belo w:Includes data-dri v en clocking, a v oiding the need for timer -dri v en transmission as cited in [6 ].TCP is widely kno wn and understood.Pro vides inherent stability because A CK-clocking k eeps the number of pack ets from each o w constant. Hence it not only controls the transmission rate, b ut also limits the maximum number of outstanding pack ets according to congestion windo w size.W indo w-based TCP protocols ha v e already been implemented in the Internet and found to be practically TCP-Friendly and f air to each other Ev enthough a number of windo w-based solutions ha v e been proposed for streaming media applications, no one has been widely deplo yed in the Internet. 2

PAGE 12

1.3 Contrib utions of This Thesis The main contrib utions of the thesis w ork are as follo ws:A thorough study of TCP-Friendliness of TFRC, and the ef fect of the Explicit Congestion Notication (ECN) bit on the friendliness with other TCP protocols.Design of a ne w windo w-based congestion control protocol based on TCP which is TCPFriendly Smooth, and F air tar geted to w ards streaming multimedia applications in the Internet and with the possibility of being used by data-oriented applications as well. 1.4 Or ganization of This Document The rest of the thesis is or ganized as follo ws. Chapter 2 describes the dif ferent types of transport protocols both implemented in the Internet and those proposed so f ar This gi v es an o v ervie w of the e xisting technologies in the eld of interest. In Chapter 3, the ne w congestion control algorithm is introduced and e xplained in detail. Chapter 4 details the e xperimental setup and topology for the simulations. The simulation results of the TFRC and the ne w proposed protocol are presented and discussed in Chapters 5 and 6 respecti v ely Finally Chapter 7 concludes the thesis with future directions of research in this area. 3

PAGE 13

CHAPTER 2 B A CKGR OUND AND LITERA TURE REVIEW This chapter gi v es an o v ervie w of the tw o transport protocols made a v ailable in the Internet to its applications, User Datagram Protocol and the v arious T ransport Control Protocols cate gorized as windo w-based and rate-based. This o v ervie w helps in understanding ho w the e xisting algorithms f ail to meet the requirements of streaming media applications and hence the need for a ne w algorithm.2.1 User Datagram Pr otocol (UDP) The User Datagram Protocol (UDP) is dened as a transport layer protocol by the Internet Engineering T ask F orce (IETF) in its Request F or Comments, RFC768 [2 ] in 1980. UDP pro vides a minimal transport service for non-guaranteed deli v ery of datagram pack ets between tw o communications ends. Due to its minimal transport service, UDP almost gi v es its applications direct access to the datagram service of the Internet Protocol (IP) layer The only services pro vided by UDP o v er IP are the checksumming of data and multiple xing/de-multiple xi ng of applications by port number UDP of fers an unreliable service and does not implement an y type of o w and congestion control. UDP just tak es application data, attaches source and destination address with port numbers for multiple xing/de-multiplexin g and and passes the data to the IP layer for transmission o v er the Inter net. At the recei ving end, UDP uses port numbers, IP source and destination address to deli v er data to the appropriate application. UDP does not use handshaking between the sending and recei ving transport-layer ends before sending data, hence UDP is classied as a connectionless protocol. UDP is the transport layer protocol of choice for man y applications for the follo wing reasons:Instantaneous Connection: TCP uses three-w ay handshak e to establish a connection before an y data pack ets are transmitted. This is considered a connection o v erhead and a delay is 4

PAGE 14

associated with it. UDP on the other hand starts by directly sending data pack ets and hence does not introduce delays in establishing an y connection.Null Connection State: TCP w orks by maintaining connection state in the end systems that include recei v e and send b uf fers, congestion control parameters, pack et sequence and ackno wledgment numbers. These are required by TCP to pro vide reliable service and congestion control. UDP does not maintain connection state and hence the memory o v erhead on the end systems becomes v ery less in the case of UDP .Less P ack et Ov erhead: A TCP pack et carries with it more information with it than a UDP pack et. The TCP se gment has 20 bytes of header o v erhead while UDP se gments which ha v e only 8 bytes of o v erhead.Fix ed T ransmission Rate: TCP changes its sending rate using a congestion control mechanism. It backs of f the sending rate on pack et drops responding to congestion in the netw ork. This throttling ef fect can af fect the real-time applications which requires a constant sending rate. Ho we v er UDP sends data at a x ed rate and the only constraints are the rate of data generation by the application and bandwidth a v ailability in the netw ork. Real-time applications are delay sensiti v e and cannot tolerate the v arying sending rate of TCP Further the reliability of TCP' s retransmissions is useless for interacti v e real-time applications such as Internet T elephon y and V oice Conference since retransmitted pack ets reach the destianation too late. F or these reasons, real-time applications use UDP as the transport protocol. The real problem with using UDP arises when the number of streaming media applications increases. Each application tries to grab the amount of bandwidth that satises its x ed sending rate requirement, and this leads to problems of unf airness and danger of congestion collapse as pointed in [3 ]. The unf airness problem arises due to the lack of an end-to-end congestion control in UDP which can be illustrated when a TCP o w shares a bottleneck link with a UDP o w During congestion, the TCP o w with its congestion control principles reduces its sending rate, while the unresponsi v e UDP o w tak es adv antage and use the a v ailable bandwidth. The simulation results in Section 6.2.4 sho w clearly ho w UDP interacts with TCP for dif ferent UDP sending rates in a x ed bottleneck link. When the sending rate of UDP o w is small, the TCP o ws recei v e high goodput. Ho we v er 5

PAGE 15

when the sending rate of the UDP o w is lar ger it grabs a lar ger portion of the bandwidth, while the TCP o w backs of f in response to pack et drops. The danger of congestion collapse due to unresponsi v e o ws poses the greatest threat to Inter net. The potential danger of congestion collapse w as not realized until around late 1980s [7] when it w as found that 1) connections retransmitted pack ets unnecessarily e v en if the y were deli v ered successfully to the recei v er and 2) when pack ets were using precious netw ork resources b ut nally dropped before reaching the destination. 2.2 T ransmission Contr ol Pr otocol (TCP) The T ransmission Control Protocol (TCP) w as rst de v eloped by the US Department of Defense (DOD) as a research project to interconnect a number of dif ferent netw orks. Initially TCP deli v ered basic services lik e le transfer electronic mail, and remote login. The current v ersion of TCP is of cially dened in RFC 793 [8]. TCP is a reliable transport protocol and promises guar anteed deli v ery It is connection-oriented establishing a full duple x virtual connection between tw o end points. T o establish a connection, a 3-w ay handshak e procedure is used to e xchange protocol specic information between the end systems before initiating an y data transfer The connection termination is also done gracefully once all data pack ets are deli v ered successfully The TCP protocol at the transport layer breaks the application data into chunks of best decided size called se gments, along with o v erhead information such as the source and destination port number sequence number etc. Once the se gment is sent, a timer is set, and w aits for the recei v er to ackno wledge (A CK) the se gment. If an A CK is not recei v ed before the timer e xpires, TCP retransmits the se gment. TCP also maintains a checksum on its header and data to ensure the pack et' s inte grity while in the netw ork. P ack et reordering is also done if necessary to ensure data reception in correct order by the end application. The chief feature of TCP is its Flo w and Congestion control. Flo w control checks for b uf fer space at the end systems and slo ws do wn the data transfer rate if the b uf fer capacity is reached. Hence TCP limits the sender to send only as much data as the recei v er can handle. Flo w control only a v oids the sender from o v ero wing the recei v er' s b uf fer b ut it does not tak e into account the b uf fers of intermediate nodes, i.e., netw ork congestion. 6

PAGE 16

T o solv e the problem of o v erloading the netw ork nodes between end systems, TCP implements Congestion Control. While Flo w Control is an end system issue, Congestion Control is a netw ork issue. There has been a number of changes made to the basic TCP congestion control algorithm de v eloped by Jacobson, in order to ne tune and t the requirements of v arying netw ork technologies. A number of a v ors of TCP has hence been proposed for then. Most of them f all into tw o broad cate gories, namely the W indo w-based and Rate-based Congestion Control Mechanisms. The follo wing sections gi v e a brief e xplanation of these broad cate gories of TCP with some references to the related w ork in the eld. 2.2.1 W indo w-Based Algorithms The rst congestion control mechanism implemented in the Internet w as a W indo w-based algorithm. The mechanism w as de v eloped by V an Jacobson [1 ] and deplo yed in the Internet in 1988, and has been responsible for most of the Internet' s stability o v er these years. F or each connection, TCP maintains a Congestion W indo w ( cwnd ) state v ariable, which is the maximum number of pack ets outstanding in the netw ork. In other w ords, cwnd refers to the maximum number of pack ets the sender can send at an y time without w aiting for an A CK. The congestion control mechanism embedded in TCP follo w the Additi v e Increase/Multiplicati v e Decrease (AIMD) [9] strate gy whereby TCP probes for a v ailable bandwidth by increasing its cwnd size linearly and responds to congestion by decreasing its cwnd size multiplicati v ely TCP interprets a timeout or pack et loss as a sign of congestion and decreases the cwnd while successful receipt of A CKs for all pack ets sent during the last Round T rip T ime (R TT) as a sign to increase the cwnd Apart from congestion control mechanisms, congestion a v oidance plays a great role in the real stability of the Internet. Both the mechanisms are basically resource management problems. The k e y of the congestion a v oidance scheme is the algorithm used to increase or decrease the rate, allo wing the netw ork to operate in the optimal re gion of lo w delay and high throughput [9 ]. The increase and decrease parameters are designated asandrespecti v ely such thatnandrnnis satised. In normal TCP the v alues of these parameters areand, meaning that the cwnd is increased by one e v ery R TT and decreased by half its current v alue after a pack et drop is detected. 7

PAGE 17

The initial TCP had three phases in the cwnd v ariation. The y are Slow Start Cong estion A voidance and F ast Retr ansmit Slo w Start does not pre v ent congestion, b ut reduces the b urst ef fect when a host starts transmitting pack ets. As dened in the RFC [8 ], during Slo w Start phase, the cwnd is increased e xponentially; doubles e v ery R TT The Slo w Start phase ends when the cwnd v alue reaches a threshold called the Slow Start Thr eshold (ssthr esh) Once the Slo w Start phase ends, the Congestion A v oidance phase is entered where the cwnd is increased linearly; increase by one se gment e v ery R TT During this phase, the connection is in a safe mode and monitors the netw ork for an y congestion. Once a pack et drop e v ent occurs, the sender is notied of the same using timeout due to absence of A CK from the dropped pack et. TCP responds by dropping the cwnd v alue to one and Slo w Start phase is entered. Instead of w aiting for the timeout to occur TCP enhances the pack et drop notication using F ast Retransmit, whereby reception of three DUP A CKs by the sender triggers a cwnd decrease. Since this occurs before the timeout period, it impro v es netw ork throughput. The abo v e mechanisms are collecti v ely named as TCP T ahoe [1]. A mechanism called the F ast Reco very w as introduced to TCP T ahoe that replaces Slo w Start when F ast Retransmit is used. While DUP A CKs indicate that a se gment has been lost, it also indicates that successi v e pack ets are deli v ered to the recei v er which tells that the netw ork is not fully congested. Therefore the sender drops cwnd to half its pre vious v alue and stays in the Congestion A v oidance phase. The F ast Retransmit mechanism is called TCP Reno [10 ]. The Ne wr eno [11 ] modication to the TCP' s F ast Retransmit algorithm describes a modication to Reno to co v er situations in which A CKs do not co v er for all of the outstanding data when loss w as detected. Figure 2.1 sho ws the v ariation of congestion windo w in TCP with the dif ferent phases. TCP Sac k (Selecti v e Ackno wledgment) [12 ] is a conserv ati v e e xtension of Reno' s congestion control, in which it uses the same AIMD strate gy and minimal changes to other congestion control algorithms. Sack implementation dif fers from Reno when multiple pack ets are dropped in a single windo w of data, where Sack responds to pack et drops only once within a congestion windo w A number of research on the Sack protocol has been done. [13 ] compares TCP Sack with T ahoe and Reno protocols, the then most common reference implementations of TCP and sho ws that without Selecti v e Ackno wledgment, TCP implementations are constrained to either retransmit at most one dropped pack et per R TT or to retransmit pack ets that might ha v e already been successfully deli v ered. The TCP Sack protocol has also been v eried to be safe to be deplo yed in the Internet 8

PAGE 18

cwnd_packet loss Timeout ssthresh ssthresh ssthresh Fast detected Recovery Slow Start CongestionAvoidance Time (Sec) Figure 2.1 Cwnd Graph Sho wing Slo w Start, Congestion A v oidance and F ast Reco v ery Phases In TCPin the paper [14 ]. The authors ha v e sho wn that SA CK can actually impro v e the time it tak es for the sender to reco v er from pack et losses. TCP V e gas [15 ] adopts a more sophisticated bandwidth estimation scheme. It uses the dif ference between e xpected and actual o w rates to estimate the a v ailable bandwidth in the netw ork. The rationale is that the dif ference in the rate gi v es an idea of ho w much the netw ork is congested. According to [16 ], V e gas achie v es between 40 and 70% better throughput, with one-fth to onehalf the losses, as compared to the Reno TCP implementation. Se v eral studies ha v e been made comparing the v arious TCP v ersions. In one such study it w as concluded that TCP V e gas achie v es higher throughput, fe wer pack et retransmissions, and leads to a f air allocation of bandwidth for dif ferent delay connections. Ho we v er when competing with TCP Reno and TCP Sack, TCP V e gas connections are penalized due to the aggressi v e nature of Reno and Sack [16 ]. An e xtension of the AIMD strate gy is the Gener al AIMD (GAIMD) proposed in [17 ]. Instead of usingandas the increase/decrease parameter v alues, GAIMD proposes a general case such that the increase/decrease ratio are parameters. A simple relationship betweenandfor a GAIMD o w to ha v e approximately the same sending rate as that of a TCP o w has been found which is as follo ws: (2.1) 9

PAGE 19

The abo v e relationship of fers a wide range of the v alues ofandfor GAIMD to be TCPFriendly Simulation results from [17 ] sho w that for GAIMD o ws with v alues!"$# and%'&()competing for bandwidth with TCP Reno o ws and TCP Sack o ws, on a DropT ail as well RED [18 ] queue are highly TCP-Friendly Further with*&()instead of, GAIMD o ws ha v e less uctuations in sending rate as compared to TCP D. Bansal and H. Balakrishnan proposed a class of nonlinear congestion control algorithms called Binomial Algorithms [19 ]. Binomial algorithms generalize TCP-style additi v e-increase by increasing in v ersely proportional to a po wer+of the current windo w; the y generalize TCP-style multiplicati v e-decrease by decreasing proportional to a po wer,of the current windo w where for TCP-compatibility+.-/,0; and+.-1,32$45+768,:9. T o generalize the AIMD rules, Binomial algorithms use the follo wing the increase/decrease rule.;=A@(BCEDB:F(GIHKJMLNOGIH GQP H 4rR2S TUBV>A@WBVC$DB:FWG HKJYXZH NOGIH GQ[ H 4\.n]rn%(2.2) From the abo v e equation, for+1^$4_,`a, we get AIMD or the normal TCP Among the f amily of Binomial algorithms, the paper proposes tw o interesting TCP-compatible algorithms. F or+bc6d,eO, the Binomial algorithm is called the IIAD (In ver se-Incr ease/ Addit ive -Decr ease ) because its increase rule in in v ersely proportional to the windo w size. F or+\^E6f,g', it is called the SQRT because both its increase is in v ersely proportional and decrease proportional to the square-root of the current windo w The simulations sho w that both IIAD and SQR T interact well with TCP AIMD o v er a wide range of netw ork conditions. The Binomial algorithms were moti v ated by the needs of streaming audio and video applications. Their simulation studies sho wed good performance and interactions between Binomial algorithms and TCP especially with RED queue. Also the authors in [20 ] compared the performance of v arious congestion control schemes with the Binomial algorithms in terms of throughput, loss rate, number of timeouts, f airness and the de gree of self-similarity The y concluded that with suf ciently lar ge number of competing o ws (50 o ws in their simulations), TCP and TCP-compatible Binomial algorithms compete f airly A recently proposed sender side modication of TCP congestion control is the TCP W estwood (TCPW) [21 ]. TCPW uses bandwidth share estimation technique to enhance TCP Reno congestion 10

PAGE 20

control o v er high speed netw orks. TCPW w orks by continuously estimating the rate of A CK returns at the TCP source. The estimate is then used to compute the congestion windo w and Slo w Start threshold ( ssthr esh ) after a congestion episode. The A CK ltering is obtained by using a discretized continuous lo w-pass lter Details of the algorithm using the lo w-pass lter are discussed in [22 ]. Simulation and e xperimental studies [21 ] of TCPW sho w signicant impro v ements in throughput performance o v er TCP Reno and Sack v ersions. Though TCPW e xhibits superior performance with respect to Friendliness and F airness, the throughput v ariation is still a concern and hence unsuitable for streaming multimedia applications. 2.2.2 Rate-Based Algorithms Recent research on congestion control algorithms ha v e inspired man y researchers to design an entirely ne w protocol, dif ferent from the normal W indo w-based congestion control. The class of algorithms called Equation-based congestion control uses a well kno wn formula that characterizes the throughput of a TCP connection under steady state [5 ]. Therefore the protocol is guaranteed to be TCP-Friendly 2.2.2.1 TCP-Friendly Rate Contr ol Pr otocol The most important equation-based congestion control protocol proposed is the TCP-Friendly Rate Control (TFRC) protocol [5 ]. The primary goal of TFRC is not to aggressi v ely nd and use a v ailable bandwidth, b ut to maintain a relati v ely steady rate to satisfy the requirements of streaming applications while still being responsi v e to congestion. The choice of control equation for TFRC is the response function that describes the steady-state sending rate of TCP Gi v en the loss rate and R TT of the connection, the follo wing equation describes the throughput of TCP (RFC 3448) [23 ]:h D iej lknm o -qp Lsr7tI j o knm u Kv wxv (2.3) wherehis the upper bound on the sending rate in bytes/sec,Dis the pack et size in bytes,iis the Round T rip T ime in secs,vis the steady-state loss rate,p Lsr7tis the TCP retransmission timeout in secs, andyis the number of pack ets ackno wledged by a single TCP ackno wledgment. F or the v alue 11

PAGE 21

ofy, TCP does not use delayed ackno wledgment and hencey:z. The increase and decrease rate of the sending rate has been analyzed in [5 ]. Gi v en a x ed R TT and absence of history discounting, TFRC' s increase in transmission rate is limited to about 0.14 pack ets per R TT After an e xtended absence of congestion, history discounting be gins and TFRC be gins to increase its sending rate by 0.22 pack ets per R TT The responsi v eness analysis indicates that TFRC requires from four to eight R TTs to halv e its sending rate in response to persistent congestion. Se v eral papers ha v e been published analyzing the TFRC protocol. A comparison of TFRC and AIMD congestion control has been made in [24 ]. The paper uses TCP(a,b) cong estion contr ol referring to AIMD that uses an increase parameterCand a decrease parametery. The re gular TCP is represented by TCP(1,1/2). The ob vious choice for a congestion control mechanism that reduces its sending rate more smoothly than TCP w ould be TCP(a,b) with v alue ofyless than 1/2. The paper sho ws that TCP(1/5,1/8) and TCP(2/5,1/8) compete f airly with TCP and with TFRC, while TFRC changes its sending rate more smoothly than others. The SlowCC paper [25 ] in v estigates the beha vior of slo wly-responsi v e, TCP-compatible congestion control algorithms under more realistic dynamic netw ork conditions. The simulation en vironment uses a ON/OFF square-w a v e CBR source to simulate the v arying dynamic netw ork scenario. The dra wbacks of the SlowCC algorithms in highly v ariable en vironments are the unf airness with respect to TCP and each other and potentially lo wer bottleneck link utilization. The SlowCC mechanisms lose to TCP under dynamic conditions in the long run because their response to netw ork conditions is slo w and the y do not transmit data f ast enough to mak e use of a v ailable bandwidth. The potential benets of SlowCC algorithms is the smoothness in sending rate. While TFRC has a perfect smoothness metric 1 of, TCP has a smoothness metric off{y. The SlowCC paper concludes that most of the TCP-compatible algorithms studied appear to be safe for deplo yment. Ho we v er in return for smoother transmission rates, slo wly-responsi v e algorithms lose throughput to f aster ones lik e TCP under dynamic netw ork conditions. An e xtensi v e study of TFRC Friendliness and its interaction with TCP protocols under more realistic netw ork conditions w as done in [26 ]. The paper also studies the ef fect of the Explicit Congestion Notication (ECN) [27 ] mechanism on TFRC. The paper concludes that TFRC can be safely deplo yed in the Internet, and the use of ECN actually helps in achie ving e v en better f airness. 1 The smoothness metric is dened as the lar gest ratio between the sending rates in tw o consecuti v e R TTs. 12

PAGE 22

Ho we v er f airness is achie v ed if TFRC competes with TCP T ahoe, Ne wreno, and Sack, while TCP V e gas, and Binomial algorithms (SQR T and IIAD) when competing with TFRC, result in unf airness both in static and dynamic netw ork conditions. 13

PAGE 23

CHAPTER 3 SF-SA CK: SMOO TH FRIENDL Y PR O T OCOL In this chapter the algorithm and w orking of the proposed SF-SA CK TCP protocol is e xplained in detail. 3.1 Congestion W indo w Estimation The windo w-based TCP algorithms v ary the transmission rate by v arying the congestion windo w ( cwnd ). The v alue of cwnd is increased during re gular A CK reception which corresponds to a successful deli v ery of a pack et at the recei v er and decreased during either a DUP A CK or a T imeout corresponding to a pack et drop in the netw ork. Since the transmission rate directly depends on cwnd an y drastic change to this v alue will ha v e a direct ef fect on the v ariation of the transmission rate. This is the case of TCP when it reduces the cwnd by half, or e v en w orse, to one after three DUP A CKs or a T imeout, respecti v ely It can be said that TCP' s responsi v eness to congestion is the main cause why this protocol is not suitable for streaming applications, and this is e xactly main focus of this thesis. The proposed algorithm attempts to reduce the v ariation of cwnd by implementing a Lo w-P ass lter to estimate the ne w cwnd v alue which depends on control parameters based on history information. 3.2 Lo w-P ass Filter One simple w ay to address the problem of drastically v arying the cwnd v alue is to smooth its v alue before using it to set the actual congestion windo w Ho we v er a simple weighted mo ving a v er age of the kind used by TCP for the estimation of R TT does not ef ciently lter out high frequenc y components of the cwnd measurements. Hence a discrete time lter obtained by discretizing a continuous lo w-pass lter using the T ustin Approximation 1 [28 ] as proposed in the TCP W estw ood 1 The T ustin Approximation is also called bilinear transformation or trapezoidal rule 14

PAGE 24

paper [22 ] is utilized. Using this lter the estimate of the congestion windo w ( cwnd estimate ) is calculated as follo ws:>AGQxGQAGgAGgAGgAGg
PAGE 25

PR OCEDUREestimate ne w cwnd () current cwnd = cwnd ; if ( rst decrease = TR UE ) /* On rst drop e v ent, it beha v es as re gular TCP */ cwnd estimate = last cwnd sample = current cwnd / 2; last drop time = no w; return cwnd estimate; endif drop interv al = no w last drop time; if ( TIMEOUT ) cwnd sample = 1; else cwnd sample = current cwnd / 2; endif /* Using W indo w Estimation F ormula from Equation 3.1 */ cwnd estimate = cwnd estimate (2*tau /drop interv al-1) / (2*tau /drop interv al +1) + (cwnd sample + last cwnd sample) / (2*tau /drop interv al + 1); last cwnd sample = cwnd sample; last drop time = no w;END PR OCEDURE Also, we kno w the lter cut-of f frequenc y is equal to 1/. According to the Nyquist sampling theorem [29 ], a signal must be sampled atleast at a frequenc y twice the maximum frequenc y component of the signal. Accordingly in order to sample the signal with a frequenc y of, a sampling interv al less than or equal to/2 is necessary In other w ords, the v alue of cwnd estimate needs to be updated e v ery/2 seconds. But, pack et drop e v ents depend on netw ork conditions and hence are irre gular Therefore the sampling frequenc y is not guaranteed, which might af fect the Lo w-P ass lter ef fect. In order to preserv e the Lo w-P ass lter ef fect, a scheduler is used which runs e v ery/2 seconds to update the estimate. In the case of a scheduler update, the cwnd sample is set to the current cwnd v alue. The time interv alp P p P„ƒM…equals/2, and so Eqn. 3.1 reduces to the follo wing:>AGQAGgAGgAGg
PAGE 26

3.3 Explanation of The Algorithm t k t k-1 t k+1 k+2 t k t k-1 Ž   ‘ timeout event cwnd_estimate cwnd_estimate cwnd_ = 1 t t/2 packet dropevent at 'k-1' packet dropevent at 'k' k-1 k last_cwnd_sample event at 'k+1' scheduler update at 'k+2' cwnd_sample Time (Sec)cwnd_ (# packets) Figure 3.1 Snapshot of Cwnd V ariation Sho wing the W orking of SF-SA CK Algorithm In order to better e xplain the proposed algorithm, Fig. 3.1 sho ws a snapshot of the congestion windo w v ariation of a single o w The bold line sho ws the actual v ariation of cwnd while the dashed line sho ws the v ariation a normal TCP connection w ould ha v e tak en. The dotted v ertical lines are the time when scheduler runs e v ery/2 seconds. Hence the time interv al between tw o dotted lines is/2 seconds. There are tw o cases in the algorithm depending on the type of congestion e v ent and the time when the e v ent occurs. As it can be seen, congestion e v ents can occur within the time interv al of/2 or the time interv al can e xpire before the ne xt the congestion e v ent occurs, in which case, the scheduler is run to update the congestion windo w estimate. The tw o cases are e xplained belo w: CASE I: Congestion e v ents within’?“$”interv als (• P„ƒM…w– • P.— ’M“$”) In this case, congestion e v ents happen within theinterv al either because of 3 DUP A CKs or TIMEOUT e v ents. In Figure 3.1 this case is sho wn with congestion e v ents atp P„ƒM…andp P. At timep Pa pack et drop occurs, and assuming we ha v e the information from last drop e v ent or a scheduler update e v ent, the estimated cwnd v alue is used to decrease the cwnd of the o w The black 17

PAGE 27

square points sho w the estimated cwnd while the white square points sho w the cwnd without the proposed algorithm, which is equal to cwnd /2 at timep P„ƒM…. If we ha v e another pack et drop e v ent occuring at timep P, within the same time interv al/2, history information about the lter parameters at timep P„ƒM…, which are>xGQAGgAGg
PAGE 28

3.4 Finding Optimal Cut-Off Fr equency The Lo w-P ass Filter by design uses a cut-of f frequenc y of 1/to lter out all frequenc y components abo v e this threshold. The choice of this frequenc y threshold is important as it acts as a smoothing f actor in estimating the ne w cwnd A lo w cut-of f frequenc y leads to high sampling rate and hence better estimation and vice-v ersa. In order to nd the optimal cut-of f frequenc y that gi v es us the minimal v ariation in cwnd simulations were run for dif ferentv alues. It w as observ ed that the optimal v alue is™‡$#š. The simulation results are presented in Section 6.1. 3.5 K ey F eatur es of the New Algorithm The proposed algorithm has been found to drastically impro v e smoothness in transmission rate and hence aptly t the requirements of streaming multimedia applications. The ne w algorithm has been deri v ed from TCP Sack and hence has all the benets enjo yed by TCP Sack protocol, in addition to being a W indo w-based congestion control algorithm. The proposed algorithm also is found to compete f airly with e xisting TCP v ersions. Moreo v er it can be used to carry both audio/video as well as data pack ets without compromising the throughput and still be f air to each other Considering all the abo v e features of the ne w algorithm it is named as SF-SA CK which stands for Smooth F riendly SA CK protocol. Some of the k e y features of SF-SA CK which might score o v er other related congestion control algorithms lik e TFRC for streaming multimedia applications are:SF-SA CK relies only on the information a v ailable in the e xisting TCP header and hence does not introduce an y o v erhead in the netw ork.SF-SA CK requires changes only in the transport layer and not from an y lo wer layers, and thus adheres to layer separation and modularity principles.The code modications needed to implement SF-SA CK are comparable to that needed for TFRC, which is complicated.SF-SA CK requires only sender side modications. 19

PAGE 29

CHAPTER 4 SIMULA TION T OPOLOGY AND P ARAMETERS This chapter describes the simulation topologies and scenario' s used for performance e v aluation of the Rate-based TFRC protocol as well as the SF-SA CK protocol with e xisting TCP algorithms. The simulations are done using the Netw ork Simulator ( ns-2 ) [30 ] v ersion 2.1b8 under the Linux operating system. Ns-2 is a discrete e v ent netw ork simulator widely used by researchers in the eld of netw orking. The simulation topology is broadly di vided into tw o main cate gories depending on the netw ork conditions. Much of the pre vious research w ork w as done on static netw ork conditions where the netw ork parameters such as bottleneck bandwidth and congestion le v el are constant throughout the simulation time. Though this netw ork scenario could e xplain the w orking of a protocol in an ideal case and its interaction with other protocols, it does not present the reality Hence the idea of a more realistic dynamic netw orking en vironment that could closely emulate today' s Internet w as proposed in the SlowCC paper [25 ]. The topologies for the both the static and dynamic netw ork scenario are e xplained in the follo wing sections. 4.1 Static Netw ork Scenario The basic topology used is the simple and standard dumbbell topology as sho wn in Figure 4.1. There is a single bottleneck link connecting tw o routers R1 and R2, that carries the traf c from all competing o ws. The bottleneck bandwidth used is both 15 Mbps and 60 Mbps for tw o independent simulations with 20 ms of propagation delay The sources are connected to Router R1 and the sinks to Router R2. All links from source to router and sink to router ha v e 100 Mbps bandwidth and a propagation delay of 2 ms unless otherwise stated. The pack et size for all o ws is set to 1000 bytes and the A CK size is the def ault v alue of 40 bytes. F or Binomial Algorithms (SQR T and IIAD) [19 ], as suggested by the authors,\# ‹and\›is used. The topology parameters are summarized in T able 4.1. 20

PAGE 30

... ... ... ... 2 ms 100 Mbps100 Mbps 2 ms Drop-Tail Sink TCP2Sink TCP1 n flows TCP2n flows 60 Mbps, 20ms, RED Bottleneck Link Drop-Tail 100 Mbps Drop-Tail 100 Mbps Drop-Tail Router 1 Router 2 Source Source TCP1 Figure 4.1 The Dumbbell Simulation T opology for Static Netw ork Scenario T able 4.1 P arameters and their V alues of the Dumbbell T opology P arameter V alue Bottleneck Bandwidth 15, 60 Mbps Bottleneck Delay 20 ms Source/Sink to Router Bandwidth 100 Mbps Source/Sink to Router Delay 2 ms P ack et Size 1000 bytes A CK Size 40 bytes (def ault) A QM at Bottleneck link RED Queue A QM at other links DropT ail Queue Application at Source FTP The Acti v e Queue Management (A QM) mechanism utilized at the bottleneck link is RED [18 ]. The parameters of the RED queue used in the follo wing simulations are deri v ed from the Slowcc paper [25 ]. In order to set the RED queue parameters, the Bandwidth Delay Product (BDP) is used. BDP (in bytes) is the product of bottleneck bandwidth (in bytes/sec) and the bottleneck delay (in secs). The RED queue size is set to 2.5 times the BDP and the thr esh and maxthr esh are set to 0.25 and 1.25 times the BDP respecti v ely The g entle option of RED is turned on as recommended in [31 ]. T able 4.2 summarizes the RED queue parameters. 21

PAGE 31

T able 4.2 RED Queue P arameters P arameter V alue Queue Size 2.5 BDP Minimum Threshold, thr esh 0.25 BDP Maximum Threshold, maxthr esh 1.25 BDP P ack et Drop Probability in v erse, linterm 10 Queue W eight, q weight 0.05 g entle bit true Congestion Indication Bit, setbit true 4.1.1 P erf ormance Metrics The W indo w-based congestion control protocols use the Congestion W indo w as the means to v ary the transmission rate of the o w and hence has a direct relation on the v arying transmission rate. The v ariation of Congestion W indo w o v er time is used as a measure to compare the dif ferent protocols. Another important performance parameter is the Throughput. The amount of v ariation of Throughput gi v es a measure of smoothness of the o w which is an important consideration in designing a TCP protocol for streaming multimedia applications. The Throughput vs T ime graphs are dra wn using the simulation trace data of pack ets at the bottleneck link. The Throughput is calculated at 0.5 seconds interv al. In addition to graphical represenation of smoothness of transmission rate, we nd the Mean, Standard De viation and Co-ef cient of V ariation (CoV) of the Throughput for both competing o ws. The CoV gi v es a mathematical estimate of v ariation of Throughput. T o nd the performance of a protocol in terms of TCP-Friendliness, one or more o ws of tw o dif ferent class of TCP Protocols compete for a bottleneck bandwidth. The Normalized Throughput of each o w from both the class of protocols is then calculated. The Normalized Throughput and the F airness Inde x gi v es pro vides a measure of the TCP-Friendliness of the tw o protocols in question. Increasing the number of competing o ws of both class of TCP protocol results in increased congestion in netw ork and gi v es an opportunity to observ e the beha vior of TCP-Friendliness of the tw o protocols during increased congestion. The Normalized Throughput graphs utilized to sho w these results can be intrepreted as follo ws. The marks on the graph correspond to the Normalized Throughput of indi vidual o ws. The dashed and dotted lines sho w the A v erage Normalized Throughput of the tw o protocol v ersions. The X22

PAGE 32

axis sho ws the number of o ws of each TCP protocol v ersion. F or e xample, a v alue of 2 in the X-axis represents 2 TCP1 o ws and 2 TCP2 o ws, corresponding to the 2 '+' and 2 'x' marks. The Normalized Throughput (in bytes/sec) for each o w (œ h3 ,Œ Gf }†) is calculated as follo ws:œ h3 ,Œ Gf }†Ÿ¡  pl¢ @ £s¤E¢(v£p  D } < ¤¦, B  ,Œ G y C=
PAGE 33

... ... ... ...ON/OFF CBR Rate 2 ms 100 Mbps100 Mbps 2 ms DropTail Sink TCP2Sink TCP1 TCP1n flows TCP2n flows 15 Mbps, 20ms, RED Bottleneck Link DropTail 100 Mbps DropTail 100 Mbps DropTail Router 1 Router 2 Source Source ON/OFF CBR Source CBRSink 100 Mbps 0 B/3 Period Magnitude Figure 4.2 The Dumbbell Simulation T opology for Dynamic Netw ork Scenario Sho wing the ON/OFF Square-W a v e CBR Source 4.2.1 P erf ormance Metrics In this scenario, the main performance metrics utilized are the Long-T erm F airness and the Short-T erm / T ransient F airness. The Long-T erm F airness is calculated o v er a long period of time, be yond the transient period when the netw ork is e xpected to be stabilized. In the rapidly changing scenario, the bandwidth consumption is periodically increased to three times its lo wer v alue using a Squar e-W ave CBR source. The topology consists of twp groups of o ws, each of a dif ferent TCP protocol class. A CBR o w is also connected to Router R1 and a corresponding CBR Sink connected to Router R2 using a 100 Mbps link. The bottleneck bandwidth is 15 Mbps, and the rate of the CBR source will be 10 Mbps in the ON state. Hence, when the CBR source is ON the a v ailable bandwidth at the link for the o ws will be 5 Mbps, and when the source is OFF the o ws ha v e 15 Mbps a v ailable. Thus the a v ailable bandwidth is v aried in the ratio 3:1. The length of ON/OFF period is v aried with each simulation, by starting and stopping the CBR source at re gular interv als. The total simulation time is set to 200 secs. The X-axis of the graph sho ws the combined length of ON/OFF time period of the CBR source and Y -axis sho ws the Normalized Throughput. T ransient F airness is measured using tw o o ws of the same congestion control algorithm b ut starting with unequal shares of link bandwidth and nding the time it tak es them to con v er ge to f airness. In [25 ] this is dened as the-fair con ver g ence time or the time tak en for tw o o ws to go 24

PAGE 34

from a bandwidth allocation of ry„65y‚tol ˆ-S  E6 gr  W. Here, the bottleneck bandwidth is‚Wy‰v D, Flo w 1 is connected to Router 1 by a 15 Mbps link, while Flo w 2 uses a 100 Mbps access link. F or the rst 20 secs, a CBR source of rate 14.9 Mbps is ON using the same access link used by the Flo w 1 b ut its traf c is routed to a dif ferent output port in Router 1 (not using the 10 Mbps bottleneck link). In this manner from time 0 to 20 secs, Flo w 1 obtains 0.1 Mbps of the bottleneck bandwidth while o w 2 obtains almost 10 Mbps. After the CBR source is OFF Flo w 1 tries to grab the bottleneck bandwidth. Thus, we are interested in measuring the time tak en from the initial unf air allocation of 68=to con v er ge to $# ‹(‹ 68$# ‹ Here is the total bandwidth a v ailable, andyxis the small bandwidth used up by Flo w 1 initially The v alue ofused is 0.1. 25

PAGE 35

CHAPTER 5 PERFORMANCE EV ALU A TION OF TCP-FRIENDL Y RA TE CONTR OL PR O T OCOL This Chapter presents and discusses the results of simulations comparing TFRC with other TCPFriendly protocols. W e start by in v estigating the beha vior of the protocols under static conditions. W e look at the F airness problem when TFRC Rate-based o ws compete with other protocols. W e look at the steady state throughput achie v ed by these protocols as the number of o ws sharing the bottleneck is increased. W e then discuss the ef fect of enabling the ECN bit. Finally we analyze these protocols under Dynamic Netw ork Conditions looking at Long-T erm and Short-T erm F airness as well as Con v er gence T ime. 5.1 Static Netw ork Conditions The topology e xplained in Chapter 4 is used to run simulations comparing TFRC with all other o ws. The netw ork conditions are static, since the bottleneck bandwidth a v ailable to the o ws does not change with time and all applications are of the same nature (ftp applications with innite amount of data to transmit) go v erned by the congestion control algorithms of the chosen transport layer protocols. Moreo v er the o ws are unidirectional, as we do not consider an y re v erse o w of data e xcept the o w of A CKs. W e use normalized throughput, drop rates, and f airness inde x as the parameters for comparison. Each of them are discussed under the subsections belo w 5.1.1 Normalized Thr oughput The Normalized Throughput parameter is e xplained in Section 4.1.1 of Chapter 4. The simulation results are sho wn in Figure 5.1. One general observ ation from the graphs in Figure 5.1 is that TFRC o ws get more bandwidth than the TCP competing v ersions and less bandwidth than the rest of the protocols. When competing with equal number of T ahoe o ws, the normalized throughput of TFRC increases as the number of 26

PAGE 36

0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput Number of TFRC flows, number of Tahoe flows. 60Mb/s RED Queue TFRC Tahoe Mean TFRC Mean Tahoe 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput Number of TFRC flows, number of Reno flows. 60Mb/s RED Queue TFRC Reno Mean TFRC Mean Reno 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput Number of TFRC flows, number of Newreno flows. 60Mb/s RED Queue TFRC Newreno Mean TFRC Mean Newreno 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput Number of TFRC flows, number of Sack1 flows. 60Mb/s RED Queue TFRC Sack1 Mean TFRC Mean Sack1 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput Number of TFRC flows, number of Vegas flows. 60Mb/s RED Queue TFRC Vegas Mean TFRC Mean Vegas 0 0.5 1 1.5 2 2.5 0 20 40 60 80 100 120 Normalized Throughput Number of TFRC flows, number of GAIMD(1,0.125) flows. 60Mb/s RED Queue TFRC GAIMD(1,0.125) Mean TFRC Mean GAIMD(1,0.125) 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput Number of TFRC flows, number of SQRT flows. 60Mb/s RED Queue TFRC SQRT Mean TFRC Mean SQRT 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput Number of TFRC flows, number of IIAD flows. 60Mb/s RED Queue TFRC IIAD Mean TFRC Mean IIAD Figure 5.1 Normalized Throughput of TFRC Flo ws Competing W ith Other Protocols W ith RED and W ithout ECN 27

PAGE 37

o ws increases. As the number of o ws is increased so is the netw ork congestion and therefore pack et losses occur more frequently taking TCP T ahoe to Slow Start after reducing its cwnd to 1. On the other hand, from [5 ] we kno w that it tak es TFRC around 4 to 8 R TTs to reduce its sending rate to half. As a result, we can conclude that since TFRC is less r esponsive to pack et losses than TCP T ahoe, TFRC is able to gain more bandwidth. Reno as well as Ne w Reno reduce their cwnd to half its current v alue, and hence the y are less responsi v e to pack et losses than T ahoe. This is reected in the graphs as the curv es are no w closer to 1 reducing the separation between them and meaning that better f airness is achie v ed. W e can also see that Ne w Reno is f airer than Reno to TFRC. As the congestion le v el increases, we kno w that Ne w Reno handles multiple pack et drops in a windo w of data better than Reno. The same e xplanation holds in the case of TCP Sack with TFRC as sho wn in the graph. The beha vior of V e gas with TFRC is strange compared to the other TCP v ersions. W e observ e that when the number of competing o ws is small, TFRC obtains almost 3 to 4 times the bandwidth obtained by V e gas while at higher number of o ws, the y con v er ge to f air share. This is because TFRC is more aggressi v e than V e gas in the Slo w Start phase; TFRC increases its cwnd lik e TCP i.e. e xponentially for each R TT while V e gas also increases it e xponentially b ut e v ery other R TT As a result, TFRC obtains more bandwidth when congestion is light. In addition, since the loss e v ent rate is small, TFRC will reduce its rate in a less responsi v e manner than V e gas. Ho we v er when we increase the number of o ws, and therefore congestion, TFRC sees a higher loss e v ent rate reducing its rate similar to V e gas. In the case of GAIMD(1,0.125), it is as aggressi v e as other TCP protocols (increase parameter›) b ut less responsi v e (decrease parameter›*$#šV ‹v ersus*$# ‹for TCP). GAIMD obtains more bandwidth than TFRC because it is more aggressi v e than TFRC. During Slo w Start phase, both GAIMD and TFRC double their sending rates for each R TT until a loss occurs. Ho we v er in steady state, TFRC at most increases its rate by$#šVpkts/R TT [5] compared topkt/R TT of GAIMD. GAIMD and TFRC ha v e similar responsi v eness though. From [24 ], we kno w that GAIMD(,) requiresn( …lƒs $# ‹R TTs of persistent congestion to reduce its sending rate by half. Hence, fory¡$#šV ‹, GAIMD(,) tak es more than v e R TTs to reduce the sending rate by half. From [5 ] we kno w that it tak es TFRC from 4 to 8 R TTs to reduce its rate by half, which is similar to GAIMD(1,0.125). One interesting observ ation from the graph is that these schemes present the 28

PAGE 38

highest v ariability of all since dif ferent o ws can obtain quite dif ferent throughputs. In other w ords, indi vidual users can obtain a quite dif ferent quality of service. As an e xample, T ables 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 5.7 and 5.8 sho w the Mean Normalized Throughput and the Standard De viation of all the protocols for the case of 4, 16, 32 and 64 o ws. T able 5.1 Mean Normalized Throughput and Standard De viation of TCP T ahoe When Competing W ith TFRC W ithout ECN and W ith (ECN) No. Flo ws TFRC T ahoe Tput Std.De v Tput Std.De v 4 1.06 (0.91) 0.20 (0.11) 0.92 (1.09) 0.05 (0.20) 16 1.10 (0.97) 0.09 (0.16) 0.90 (1.03) 0.12 (0.11) 32 1.14 (0.96) 0.16 (0.18) 0.86 (1.04) 0.11 (0.12) 64 1.18 (0.96) 0.23 (0.28) 0.82 (1.04) 0.15 (0.17) T able 5.2 Mean Normalized Throughput and Standard De viation of TCP Reno When Competing W ith TFRC W ithout ECN and W ith (ECN) No. Flo ws TFRC Reno Tput Std.De v Tput Std.De v 4 1.06 (0.97) 0.15 (0.04) 0.94 (1.03) 0.11 (0.09) 16 1.03 (0.97) 0.08 (0.12) 0.97 (1.03) 0.15 (0.10) 32 1.04 (1.00) 0.15 (0.17) 0.96 (1.00) 0.15 (0.11) 64 1.13 (1.00) 0.23 (0.19) 0.87 (1.00) 0.18 (0.15) T able 5.3 Mean Normalized Throughput and Standard De viation of TCP Ne w Reno When Competing W ith TFRC W ithout ECN and W ith (ECN) No. Flo ws TFRC Ne w Reno Tput Std.De v Tput Std.De v 4 1.18 (0.91) 0.20 (0.10) 0.82 (1.08) 0.36 (0.53) 16 1.01 (1.01) 0.11 (0.11) 0.99 (0.99) 0.12 (0.28) 32 1.05 (0.96) 0.16 (0.25) 0.95 (1.04) 0.21 (0.15) 64 1.05 (0.96) 0.20 (0.26) 0.95 (1.04) 0.18 (0.19) The beha vior of TFRC with Binomial Congestion Control algorithms can be e xplained on the basis of the increase/decrease beha vior of SQR T and IIAD based on Equation 2.2 compared to TCP T able 5.9 includes the formulas that TCP GAIMD, SQR T and IIAD use to increase and decrease the cwnd as well as three e xamples meant to illustrate ho w aggressi v e and responsi v e these protocols are for dif ferent v alues of the cwnd (w=1,10,100). F or small v alues of the cwnd SQR T(k=l=0.5) 29

PAGE 39

T able 5.4 Mean Normalized Throughput and Standard De viation of TCP Sack When Competing W ith TFRC W ithout ECN and W ith (ECN) No. Flo ws TFRC Sack Tput Std.De v Tput Std.De v 4 0.98 (0.89) 0.07 (0.06) 1.02 (1.11) 0.07 (0.17) 16 1.06 (0.95) 0.09 (0.17) 0.94 (1.04) 0.33 (0.12) 32 1.07 (0.97) 0.12 (0.17) 0.93 (1.03) 0.20 (0.16) 64 1.12 (0.94) 0.21 (0.27) 0.88 (1.06) 0.26 (0.14) T able 5.5 Mean Normalized Throughput and Standard De viation of TCP V e gas When Competing W ith TFRC W ithout ECN and W ith (ECN) No. Flo ws TFRC V e gas Tput Std.De v Tput Std.De v 4 1.74 (1.52) 0.30 (0.02) 0.26 (0.47) 0.04 (0.01) 16 1.59 (1.48) 0.20 (0.23) 0.41 (0.52) 0.04 (0.14) 32 1.35 (1.37) 0.20 (0.19) 0.65 (0.63) 0.20 (0.24) 64 1.11 (1.11) 0.27 (0.26) 0.89 (0.89) 0.20 (0.25) T able 5.6 Mean Normalized Throughput and Standard De viation of GAIMD When Competing W ith TFRC W ithout ECN and W ith (ECN) No. Flo ws TFRC GAIMD Tput Std.De v Tput Std.De v 4 0.69 (0.67) 0.04 (0.15) 1.31 (1.33) 0.33 (0.13) 16 0.74 (0.61) 0.05 (0.17) 1.26 (1.34) 0.42 (0.08) 32 0.76 (0.62) 0.10 (0.18) 1.24 (1.38) 0.27 (0.13) 64 0.83 (0.67) 0.16 (0.20) 1.17 (1.33) 0.33 (0.21) T able 5.7 Mean Normalized Throughput and Standard De viation of SQR T Binomial When Competing W ith TFRC W ithout ECN and W ith (ECN) No. Flo ws TFRC SQR T Tput Std.De v Tput Std.De v 4 1.59 (1.57) 0.22 (0.44) 0.40 (0.41) 0.01 (0.01) 16 0.82 (0.69) 0.07 (0.07) 1.18 (1.31) 0.04 (0.06) 32 0.72 (0.36) 0.11 (0.08) 1.28 (1.64) 0.19 (0.20) 64 0.45 (0.74) 0.16 (0.16) 1.55 (1.26) 0.37 (0.31) 30

PAGE 40

T able 5.8 Mean Normalized Throughput and Standard De viation of IIAD Binomial When Competing W ith TFRC W ithout ECN and W ith (ECN) No. Flo ws TFRC IIAD Tput Std.De v Tput Std.De v 4 1.56 (1.58) 0.16 (0.33) 0.41 (0.40) 0.01 (0.01) 16 0.78 (0.88) 0.06 (0.12) 1.22 (1.12) 0.09 (0.10) 32 0.64 (0.85) 0.07 (0.09) 1.36 (1.15) 0.19 (0.22) 64 0.52 (0.88) 0.19 (0.17) 1.48 (1.12) 0.40 (0.26) and IIAD(k=1,l=0) are a little bit more aggressi v e than TCP Ho we v er as the v alue of cwnd increases all protocols increase their rates at similar rates. In terms of responsi v eness, the story is dif ferent. IIAD(k=1,l=0) is less responsi v e than SQR T(k=l=0.5) and considerably less responsi v e than GAIMD and TCP These results are v ery much v alid for all ranges of cwnd Kno wing that TFRC is less responsi v e b ut has similar aggressi v eness than TCP and that SQR T and IIAD ha v e similar aggressi v eness than TCP b ut are considerably less responsi v e than TCP then SQR T and IIAD should obtain more bandwidth than TFRC. This is reected in the simulations and can be easily seen from the gure. The beha vior of SQR T and IIAD can be e xplained as follo ws. SQR T is more aggressi v e and also more responsi v e than IIAD. Since the pack et drop rate is rather small, there are more opportunities for the protocols to increase the congestion windo w than to reduce it, therefore, SQR T obtains more bandwidth than IIAD. In another simulation (not sho wn here) where SQR T and IIAD o ws competed against each other we corroborated this f act seeing that SQR T is not f air to IIAD. Considering that Ne w Reno and Sack are among the most implemented TCP v ersions in practice, we can conclude that TFRC can be safely deplo yed in the Internet, at least considering static conditions. In addition, based on the results of the other protocols, we don' t recommend the deplo yment of V e gas, GAIMD, SQR T and IIAD along with TFRC, at least using the parameters that we used in our w ork. V e gas beha v es dif ferently under dif ferent netw ork loads and GAIMD, SQR T and IIAD are not friendly to TFRC and present higher v ariability 5.1.2 Effect of Explicit Congestion Notication (ECN) In order to study the ef fect of ECN on the f airness of these protocols, we used the same set of simulations in section 4.1.1 of Chapter 4, b ut this time with bothBV>A< bit andD„B p§yx}p for the RED 31

PAGE 41

T able 5.9 F ormulas Corresponding to The Increase and Decrease Beha vior of cwnd of TCP GAIMD, SQR T and IIAD TCP(,) GAIMD(,) SQR T(,,,) IIAD(,,,) ,) +e‡,? +™,,?‡ # ‹, # ‹, Increase G G … G G … G G …l G G …l Decrease G G G G u G G r G G G S Inc. (w=1) 2 2 2.5 2.5 Dec. (w=1) 0.5 0.85 0 0 Inc. (w=10) 10.1 10.1 10.47 10.15 Dec. (w=10) 5 8.75 6.83 9 Inc. (w=100) 100.01 100.01 100.15 100.01 Dec. (w=100) 50 87.5 90 99 queue set. W ith ECN the router marks the Congestion Experienced (CE) bit for those pack ets f acing congestion, rather than dropping them. The recei v er uses the ECN-Echo bit to inform the sender about the pack et marking and the sender tak es usual congestion measures according to the protocol. Figure 5.2 sho ws the results of the simulations with the ECN bit set for all protocols. From the graphs with and without ECN (Figures 5.1 and 5.2, respecti v ely), we observ e that for the cases of the TCP v ersions T ahoe, Reno, Ne w Reno, and Sack better f airness is achie v ed in the ECN case. As we noted before, the TCP v ersions mentioned are considerably more responsi v e than TFRC because the y reduce their transmission rates in a considerably more drastic manner than TFRC. W ith ECN, ho we v er no w the trend re v erses and in general, the TCP v ersions obtain slightly more bandwidth than TFRC. This can be e xplained in se v eral w ays. First, no w we transmit more pack ets than should ha v e been dropped otherwise, making the TCP v ersions obtain more bandwidth at the e xpense of TFRC. W e actually e xamined the change in loss rates when we added ECN and found that the loss rates almost decreased by half compared with the no ECN cases. This deniti v ely f a v ors TCP v ersions more than TFRC. Second, with ECN TCP sources are informed about congestion sooner and the y don' t ha v e to w ait for the retransmission timer to e xpire or 3 DUP A CKs to infer that a pack et w as lost. Third, we also compared TFRC against itself with and without ECN and we did not observ e an y major dif ference meaning that ECN actually doesn' t help TFRC as such. Ev en though no w the TCP v ersions obtain slightly more bandwidth than TFRC, the general results indicate that this case is quite f airer than without ECN. From these results, we 32

PAGE 42

0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput Number of TFRC flows, number of Tahoe flows. 60Mb/s RED Queue TFRC Tahoe Mean TFRC Mean Tahoe 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput Number of TFRC flows, number of Reno flows. 60Mb/s RED Queue TFRC Reno Mean TFRC Mean Reno 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput Number of TFRC flows, number of Newreno flows. 60Mb/s RED Queue TFRC Newreno Mean TFRC Mean Newreno 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput Number of TFRC flows, number of Sack1 flows. 60Mb/s RED Queue TFRC Sack1 Mean TFRC Mean Sack1 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput Number of TFRC flows, number of Vegas flows. 60Mb/s RED Queue TFRC Vegas Mean TFRC Mean Vegas 0 0.5 1 1.5 2 2.5 0 20 40 60 80 100 120 Normalized Throughput Number of TFRC flows, number of GAIMD flows. 60Mb/s RED Queue TFRC GAIMD Mean TFRC Mean GAIMD 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput Number of TFRC flows, number of SQRT flows. 60Mb/s RED Queue TFRC SQRT Mean TFRC Mean SQRT 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput Number of TFRC flows, number of IIAD flows. 60Mb/s RED Queue TFRC IIAD Mean TFRC Mean IIAD Figure 5.2 Normalized Throughput of TFRC Flo ws Competing W ith Other Protocols W ith RED and W ith ECN 33

PAGE 43

conclude that the use of ECN is benecial and we recommend the use of ECN to increase the f airness among competing TCP and TFRC o ws. F or the rest of the protocols the conclusion is just the opposite. If the y were unf air to TFRC without ECN, no w are e v en more unf air with the addition of ECN. This applies to GAIMD, SQR T and IIAD, since V e gas is almost insensiti v e to ECN. (It is v ery important to see reference [32 ] because in the current ns-2 v ersions V e gas senders don' t respond to pack ets with the ECN bit set). Since the use of ECN reduces the pack et drop rate, the higher aggressi v eness of these protocols mak e them gain more bandwidth than before. In addition, the gure sho ws that as the number of o ws increases the separation between IIAD and TFRC o ws widens in IIAD' s f a v or while in the case of TFRC and SQR T TFRC o ws seem to stabilize or e v en get more bandwidth as congestion increases. As congestion increases, IIAD obtains more and more bandwidth than TFRC because it is less responsi v e. On the other hand, although SQR T is more aggressi v e than TFRC, the y both respond to losses in a similar w ay As in the case of GAIMD, it can be seen the big v ariability in throughputs achie v ed by dif ferent o ws. F or all these reasons we don' t recommend the deplo yment of TFRC along with TCP V e gas, GAIMD, SQR T and IIAD. 5.1.3 F air ness of TFRC Pr otocol The F airness of TFRC with other TCP-Friendly protocols is measured using the F airness Inde x parameter e xplained in Chapter 4. Figure 5.3 sho ws the F airness Inde x of TFRC o ws when competing with the other protocols under consideration while v arying number of competing o ws. From the gure it can be seen that, when then number of o ws is greater than 40, all protocols are nearly f air to TFRC. This is well within the practical limits for safe deplo yment. In Figure 5.4 we repeat the e xperiments for the ECN case. As it can be seen, no w the f airness inde x is considerably better for most cases e xcept GAIMD, SQR T and IIAD. These results were e xpected gi v en the results observ ed in Figures 5.1 and 5.2. 34

PAGE 44

0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 0 10 20 30 40 50 60 70 Fairness Index Number of Equal no. of flowtypes 1 & 2 60 Mb/s RED Queue TFRC-Sack TFRC-Reno TFRC-Newreno TFRC-Tahoe TFRC-Vegas TFRC-GAIMD TFRC-SQRT TFRC-IIAD Figure 5.3 F airness Inde x of Flo ws Competing W ith TFRC W ithout ECN 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 0 10 20 30 40 50 60 70 Fairness Index Number of Equal no. of flowtypes 1 & 2 60 Mb/s RED Queue TFRC-Sack TFRC-Reno TFRC-Newreno TFRC-Tahoe TFRC-Vegas TFRC-GAIMD TFRC-SQRT TFRC-IIAD Figure 5.4 F airness Inde x of Flo ws Competing W ith TFRC W ith ECN 35

PAGE 45

5.2 Dynamic Netw ork Scenario In order to study the responsi v eness and aggressi v eness of the competing o ws under dynamic netw ork conditions, we used the scenario utilized in [25 ], e xplained in Section 4.2 of Chapter 4. W e study both the Long-T erm and Short-T erm F airness of TFRC o ws competing with the rest of protocols under consideration. 5.2.1 Long-T erm F air ness of TFRC The long-term f airness is one which is calculated o v er a long period of time, be yond the transient period where the netw ork is e xpected to be stabilized. Here, we study the long-term f airness in a rapidly changing scenario, where the a v ailable bandwidth is periodically increased to three times its lo wer v alue using a Squar e-W ave CBR source. The results are sho wn in Figure 5.5 where in each graph the x-axis sho ws the combined length of the ON/OFF time period of the CBR source and the y-axis the Normalized Throughput. A general observ ation about TFRC is that it accomplishes its goals v ery well. Ev en in dynamic conditions, TFRC e xperiences no abrupt changes in throughput. In the case of TCP T ahoe, Reno, Ne w Reno, V e gas and SA CK, TFRC either obtains the same bandwidth or a higher portion of it for an y duration of the CBR source. This can be attrib uted to the slo w responsi v eness of TFRC. In the cases of TCP T ahoe, Ne w Reno and SA CK, we can say that these protocols can li v e together without causing much harm to each other Ho we v er the cases of TCP Reno, V e gas, GAIMD, and IIAD are not as f air In the case of Reno, TFRC is able to obtain more bandwidth when bandwidth a v ailability changes rapidly (rather short periods of high/lo w transitions of the CBR source). W e attrib ute this beha vior to the inability of TCP Reno of handling multiple drops from the same windo w of data and the slo wer responsi v eness of TFRC. W e e xpect man y pack ets to be dropped due to the sudden decrease of the a v ailable bandwidth and the rapid w ay in which these changes occur In this scenario, TCP Reno spends a lot of time in the f ast reco v ery phase and either it retransmits pack ets in an additi v e manner or it nally times out. On the other hand, TCP T ahoe does not e xperience this beha vior T ahoe times out more frequently than Reno b ut it lls the pipe with more pack ets due to the continuous Slo w Start phase (e xponentially). In the case of TCP V e gas, the unf airness of TFRC increases as the time of the ON/OFF period increases. This means that TCP 36

PAGE 46

0 0.2 0.4 0.6 0.8 1 1.2 1.4 0.01 0.1 1 10 100 Normalized Bandwidth Length of high/low bw (15Mb/5Mb) period Competing TFRC and Tahoe flows TFRC Tahoe 0 0.2 0.4 0.6 0.8 1 1.2 1.4 0.01 0.1 1 10 100 Normalized Bandwidth Length of high/low bw (15Mb/5Mb) period Competing TFRC and Reno flows TFRC Reno 0 0.2 0.4 0.6 0.8 1 1.2 1.4 0.01 0.1 1 10 100 Normalized Bandwidth Length of high/low bw (15Mb/5Mb) period Competing TFRC and NewReno flows TFRC NewReno 0 0.2 0.4 0.6 0.8 1 1.2 1.4 0.01 0.1 1 10 100 Normalized Bandwidth Length of high/low bw (15Mb/5Mb) period Competing TFRC and Sack flows TFRC Sack 0 0.2 0.4 0.6 0.8 1 1.2 1.4 0.01 0.1 1 10 100 Normalized Bandwidth Length of high/low bw (15Mb/5Mb) period Competing TFRC and Vegas flows TFRC Vegas 0 0.2 0.4 0.6 0.8 1 1.2 1.4 0.01 0.1 1 10 100 Normalized Bandwidth Length of high/low bw (15Mb/5Mb) period Competing TFRC and GAIMD I flows TFRC GAIMD I 0 0.2 0.4 0.6 0.8 1 1.2 1.4 0.01 0.1 1 10 100 Normalized Bandwidth Length of high/low bw (15Mb/5Mb) period Competing TFRC and SQRT flows TFRC SQRT 0 0.2 0.4 0.6 0.8 1 1.2 1.4 0.01 0.1 1 10 100 Normalized Bandwidth Length of high/low bw (15Mb/5Mb) period Competing TFRC and IIAD flows TFRC IIAD Figure 5.5 Long-T erm F airness of TFRC Flo ws and Competing Protocols Under Dynamic Netw ork Conditions W ith ECN 37

PAGE 47

V e gas is not a good choice for dynamic en vironments competing against TFRC. TFRC is more aggressi v e and less responsi v e than V e gas and this situation f a v ors TFRC as the amount of a v ailable bandwidth is reduced or increased for longer periods of time. TCP V e gas calculates the e xpected throughput based on the best R TT seen by the connection (when plenty of bandwidth is a v ailable) and under sudden bandwidth reductions, TCP V e gas will reduce its rate constantly at a higher rate than TFRC. In the case of GAIMD, SQR T and IIAD, these protocols are more aggressi v e and less responsi v e than TFRC and al w ays obtain more bandwidth. Looking at T able 5.9, we can see that GAIMD is the most aggressi v e protocol follo wed by SQR T and IIAD. On the other hand, IIAD is the least responsi v e follo wed GAIMD and SQR T (this actually depends on the windo ws size). The simulation results sho wn in the graphs actually reect these conclusions. 5.2.2 Short-T erm/T ransient F air ness of TFRC T ransient F airness is measured using tw o o ws of the same congestion control algorithm b ut starting with unequal shares of link bandwidth and nding the time it tak es them to con v er ge to f airness. W e use the-fair con ver g ence time as dened in [25 ]. More details about the T ransient F airness is in Section 4.2.1 of Chapter 4. T able 5.10 Con v er gence T imes (In Seconds) of V arious Protocols W ith and W ithout ECN Protocol CT No ECN CT ECN T ahoe E#Qq$#( #Q]$# Reno #gq$#(( E# q$# )W& Ne w Reno E#&]$# ‹ V E#gq$#(() Sack #šwq$#& ‹ E#Qq$# ‹ V e gas — — GAIMD E#Qq$# () E#)g]$# ) SQR T E#&]E#( ‹ )E#&g # ) IIAD $# S)E# ‹ ( VE# S&¦#šV ‹ TFRC &¦#3SE# ‹ ‹ #Qq$#&W T able 5.10 sho ws the con v er gence times of v arious congestion control algorithms in seconds. The v alues are the a v erage con v er gence times of 10 runs with 95% condence interv als. TFRC tak es the maximum time to con v er ge among the other protocols, and this is because of its less aggressi v e and responsi v e nature. TCP T ahoe con v er ges the f astest, as we kno w it reduces its cwnd toon congestion, while the increase parameter (C ) is the same as for Reno, Ne w Reno, and Sack. 38

PAGE 48

Thus the sharp responsi v e nature of T ahoe, helps in dropping its rate quickly to gi v e w ay for the competing o w IIAD is the least responsi v e of the protocols therefore it tak es more time to the competing o ws to gain bandwidth. In the case of TCP V e gas, it ne v er con v er ged to f air -share within the duration of the simulation (( DBV>‚D). Hence we can infer that V e gas is not f air to itself. 5.3 Conclusions on TFRC Pr otocol TFRC has been proposed as an alternati v e to TCP W indo w-based Congestion Control algorithms for multimedia applications. The e xtensi v e study of TFRC with respect to Friendliness and F airness with other TCP protocols under Static and Dynamic Netw ork Conditions has gi v en the opportunity to conclude about its deplo yability In general the conclusions from the simulation study are:TFRC can be deplo yed safely in the InternetThe use of ECN actually helps in achie ving e v en better f airnessTFRC in f act pro vides a smooth transmission service to streaming applicationsF airness is achie v ed if TFRC competes with TCP T ahoe, Ne w Reno and SA CKIf TFRC competes with TCP V e gas, GAIMD, SQR T or IIAD unf airness problems arise in static or dynamic conditions, or both. The parameters of these protocols could be tuned to achie v e f airness b ut cannot guarantee that the y will w ork well under all scenarios. On the other hand, TFRC, T ahoe, Ne w Reno and SA CK don' t need an y parameter tuning. 39

PAGE 49

CHAPTER 6 PERFORMANCE EV ALU A TION OF SF-SA CK PR O T OCOL This Chapter presents the results of simulations comparing SF-SA CK with other TCP-Friendly protocols under both Static and Dynamic Netw ork Scenario' s. 6.1 Optimal Cut-Off Fr equency () of Lo w-P ass Filter In order to nd out the optimal cut-of f frequenc y of the Lo w-P ass lter to achie v e minimal v ariation in congestion windo w simulations are run to plot the congestion windo w v ariation at dif ferent v alues of. A lo w cut-of f frequenc y leads to high sampling rate and vice-v ersa. Figure 6.1 sho ws a 3D graph of v ariation of cwnd o v er time for dif ferentv alues. The simulation is run for 300 secs using tw o competing SF-SA CK o ws and the bottleneck bandwidth used is 60 Mbps. The Figure sho ws that the v ariation of cwnd is minimal at‡$#š. Hence for further performance e v aluations of SF-SA CK we assume the v alue ofrz$#š. When the simulations were run again with a bottleck bandwidth of 15 Mbps, the results are similar as sho wn in Figure 6.2. 40

PAGE 50

tau 0.01 tau 0.05 tau 0.1 tau 0.5 tau 1.0 tau 2.0 tau 4.0 tau 10.0 Cut-off Frequency Parameter (tau) 0 50 100 150 200 250 300 Time (sec) 0 50 100 150 200 250 300 350 400 450 Congestion Window Figure 6.1 3D Graph Sho wing V ariation of cwnd W ith T ime for Dif ferent tau V alues Using 60 Mbps Bottleneck Link tau 0.01 tau 0.05 tau 0.1 tau 0.5 tau 1.0 tau 2.0 tau 4.0 tau 10.0 Cut-off Frequency Parameter (tau) 0 50 100 150 200 250 300 Time (sec) 0 20 40 60 80 100 120 140 Congestion Window Figure 6.2 3D Graph Sho wing V ariation of cwnd W ith T ime for Dif ferent tau V alues Using 15 Mbps Bottleneck Link 41

PAGE 51

6.2 P erf ormance of SF-SA CK Under Static Netw ork Scenario 6.2.1 Congestion W indo w V ariation The SF-SA CK algorithm w orks by modifying the w ay the congestion windo w is reduced on e v ents of pack et drop. Hence to sho w that SF-SA CK performs better than the other protocols, a graph sho wing the v ariation of the congestion windo w o v er time will be appropriate. In order to compare the v ariation of the instantaneous v alues of congestion windo w of SF-SA CK with other protocols, the dumbell topology is used to run simulations. T w o o ws of the same class of TCP compete with other for the bottleneck bandwidth. The o ws transfer data from a FTP application for 300 secs. SF-SA CK is compared with TCP T ahoe, Reno, Ne wreno and Sack protocols. The simulation results are sho wn in Figure 6.3. From the graphs, it is observ ed that o ws of type T ahoe ha v e a highly v arying congestion windo w and is attrib uted to the basic TCP congestion control algorithm where the cwnd drops by half during DUP A CKS and by 1 on TIMEOUT TCP Reno, Ne wreno and Sack v ersions are better than T ahoe b ut still not good enough to be smooth for streaming applications. 6.3. SF-SA CK sho ws a drastic impro v ement in the congestion windo w v ariation compared to other protocols, which is also relfected in the throughput performance. Especially when compared with TCP Sack, since SF-SA CK is deri v ed from Sack, the ef fect of the proposed algorithm is clearly seen. The Rate-based protocol, TFRC does not use the congestion windo w to v ary its transmission rate and hence will not be able to compare TFRC with SF-SA CK and other TCP v ersions. Ho we v er the throughput v ariation graphs in Section 6.2.2 will gi v e an idea of the thoroughput performances of the dif ferent protocols interested. Figure 6.4 sho ws the results when the bottleneck bandwidth is reduced to 15 Mbps. The results are pretty much the same as seen for a 60 Mbps bottleneck link. 42

PAGE 52

0 50 100 150 200 250 300 350 400 450 0 50 100 150 200 250 300 Congestion Window Time (Sec) 60 Mbps, RED Queue Congestion Window Comparison Tahoe1 Tahoe2 0 50 100 150 200 250 300 350 400 450 0 50 100 150 200 250 300 Congestion Window Time (Sec) 60 Mbps, RED Queue Congestion Window Comparison Reno1 Reno2 0 50 100 150 200 250 300 350 400 450 0 50 100 150 200 250 300 Congestion Window Time (Sec) 60 Mbps, RED Queue Congestion Window Comparison Newreno1 Newreno2 0 50 100 150 200 250 300 350 400 450 0 50 100 150 200 250 300 Congestion Window Time (Sec) 60 Mbps, RED Queue Congestion Window Comparison Sack Sack2 0 50 100 150 200 250 300 350 400 450 0 50 100 150 200 250 300 Congestion Window Time (Sec) 60 Mbps, RED Queue Congestion Window Comparison SF-SACK1 SF-SACK2 Figure 6.3 Congestion W indo w V ariation of T w o Flo ws of Same Class Competing for a 60 Mbps Bottleneck Bandwidth Link 43

PAGE 53

0 20 40 60 80 100 120 140 0 50 100 150 200 250 300 Congestion Window Time (Sec) 15 Mbps, RED Queue Congestion Window Comparison Tahoe1 Tahoe2 0 20 40 60 80 100 120 140 0 50 100 150 200 250 300 Congestion Window Time (Sec) 15 Mbps, RED Queue Congestion Window Comparison Reno1 Reno2 0 20 40 60 80 100 120 140 0 50 100 150 200 250 300 Congestion Window Time (Sec) 15 Mbps, RED Queue Congestion Window Comparison Newreno1 Newreno2 0 20 40 60 80 100 120 140 0 50 100 150 200 250 300 Congestion Window Time (Sec) 15 Mbps, RED Queue Congestion Window Comparison Sack Sack2 0 20 40 60 80 100 120 140 0 50 100 150 200 250 300 Congestion Window Time (Sec) 15 Mbps, RED Queue Congestion Window Comparison SF-SACK1 SF-SACK2 Figure 6.4 Congestion W indo w V ariation of T w o Flo ws of Same Class Competing for a 15 Mbps Bottleneck Bandwidth Link 44

PAGE 54

6.2.2 Thr oughput P erf ormance of SF-SA CK The throughput parameter plays an imporant role in e v aluating the performance of a protocol. This section presents the v ariation of throughput achie v ed by v arious TCP v ersions and SF-SA CK resulting from the interaction with another connection of same type sharing the bottleneck link. The same simulation topology the dumbbell topology and paramters as mentioned in Section 4.1 are also utilized here. The tw o competing o ws use the same TCP protocol, ha v e same R TT and propogation delays. The FTP application running at both the nodes sends innite data for 300 secs. The throughput is calculated in 0.5 sec interv als from the ra w pack et trace data (trace data generated by ns ) on the bottleneck link. The main interest is in measuring the smoothness of the transmmission rate of fered by each TCP protocol when sharing the same link. Figure 6.5 sho ws the throughput v alues at 0.5 sec interv als of dif ferent TCP v ersions at bottleneck bandwidth of 60 Mbps. The throughput v alues are calculated after a initial transient period of 20 secs when the connections are belie v ed to be not stable and hence not included for throughput calculations. From the graphs, it can be seen that among the W indo w-based congestion control protocols, SF-SA CK gi v es the most smooth transmission rate and the v ariation is much less compared to other protocols. The throughput results here for each protocol reect the changes in congestion windo w as seen in Section 6.2.1. Ho we v er the throughput v ariation of TFRC o ws is better than that of SF-SA CK. This is e xpected as se v eral studies [26 ] [24 ] [25 ] ha v e pro v ed that TFRC performs well when compared to W indo w-based protocols. In order to pro v e that SF-SA CK is a smooth protocol among the W indo w-based protocols, T able 6.1 sho ws the Mean, Standard De viation, and Co-ef cient of V ariation (CoV) of the Throughput v alues for all the protocols. From T able 6.1, it can be seen that SF-SA CK considerably impro v es the v ariability of the cwnd compared among all the W indo w-based Congestion Control algorithms while being just slightly w orse than TFRC. 45

PAGE 55

0 10 20 30 40 50 60 0 50 100 150 200 250 300 Throughput (Mbps) Time (Sec) 60 Mbps, RED Queue Tahoe1 Tahoe2 0 10 20 30 40 50 60 0 50 100 150 200 250 300 Throughput (Mbps) Time (Sec) 60 Mbps, RED Queue Reno1 Reno2 0 10 20 30 40 50 60 0 50 100 150 200 250 300 Throughput (Mbps) Time (Sec) 60 Mbps, RED Queue Newreno1 Newreno2 0 10 20 30 40 50 60 0 50 100 150 200 250 300 Throughput (Mbps) Time (Sec) 60 Mbps, RED Queue Sack1 Sack2 0 10 20 30 40 50 60 0 50 100 150 200 250 300 Throughput (Mbps) Time (Sec) 60 Mbps, RED Queue SF-SACK1 SF-SACK2 0 10 20 30 40 50 60 0 50 100 150 200 250 300 Throughput (Mbps) Time (Sec) 60 Mbps, RED Queue TFRC1 TFRC2 Figure 6.5 Throughput V ariation of T w o Flo ws of Same Class Competing for a 60 Mbps Bottleneck Bandwidth Link 46

PAGE 56

T able 6.1 Mean, Standard De viation, and Co-ef cient of V ariation of Throughput V alues for V arious Competing TCP Protocols at 60 Mbps Bottleneck Bandwidth TCP V ersion Mean (Mbps) Std. De v CoV TCP T ahoe 29.2332 8.49224 29.05 27.5874 8.3984 30.4429 TCP Reno 30.2939 8.06925 26.6365 28.346 8.04155 28.3693 TCP Ne w Reno 28.6754 8.13704 28.3764 29.9783 8.1698 27.2524 TCP Sack 29.9781 8.89367 29.6672 28.6807 8.81552 30.7368 SF-SA CK 28.5192 4.17261 14.6309 31.4808 4.17266 13.2546 TFRC 31.0683 3.29835 10.6164 28.7649 3.34836 11.6405 T able 6.2 Mean, Standard De viation, and Co-ef cient of V ariation of Throughput V alues for V arious Competing TCP Protocols at 15 Mbps Bottleneck Bandwidth TCP V ersion Mean (Mbps) Std. De v CoV TCP T ahoe 7.23738 2.57435 35.5701 6.49829 2.51488 38.7007 TCP Reno 7.41315 2.13668 28.8228 7.33401 2.13178 29.0671 TCP Ne w Reno 7.29792 2.19294 30.0489 7.45219 2.19289 29.4261 TCP Sack 7.53709 2.05794 27.3042 7.18655 2.05404 28.5817 SF-SA CK 7.64743 1.17897 15.4165 7.3446 1.17893 16.0517 TFRC 7.15 0.781209 10.926 7.84263 0.781262 9.96173 47

PAGE 57

0 2 4 6 8 10 12 14 0 50 100 150 200 250 300 Throughput (Mbps) Time (Sec) 15 Mbps, RED Queue Tahoe1 Tahoe2 0 2 4 6 8 10 12 14 0 50 100 150 200 250 300 Throughput (Mbps) Time (Sec) 15 Mbps, RED Queue Reno1 Reno2 0 2 4 6 8 10 12 14 0 50 100 150 200 250 300 Throughput (Mbps) Time (Sec) 15 Mbps, RED Queue Newreno1 Newreno2 0 2 4 6 8 10 12 14 0 50 100 150 200 250 300 Throughput (Mbps) Time (Sec) 15 Mbps, RED Queue Sack1 Sack2 0 2 4 6 8 10 12 14 0 50 100 150 200 250 300 Throughput (Mbps) Time (Sec) 15 Mbps, RED Queue SF-SACK1 SF-SACK2 0 2 4 6 8 10 12 14 0 50 100 150 200 250 300 Throughput (Mbps) Time (Sec) 15 Mbps, RED Queue TFRC1 TFRC2 Figure 6.6 Throughput V ariation of T w o Flo ws of Same Class Competing for a 15 Mbps Bottleneck Bandwidth Link 48

PAGE 58

6.2.3 TCP-Friendliness of SF-SA CK Since the de v elopment of an ideal congestion control protocol meeting the requirements of a v ariety of applications is an ongoing process, it is possible that at an y point of time, the netw ork will be handling o ws of dif ferent protocol types. Apart from a congestion control protocol being friendly to o ws of its o wn type, an y protocol should also be friendly when competing with o ws of a dif ferent type. This is the major requirement for a ne w protocol to be considered for deplo yment. The TCP-Friendliness of SF-SA CK with other W indo w-based algorithms and TFRC is sho wn by nding the Normalized Throughput of competing o ws. The simulation topology is e xplained in Chapter 4. Figure 6.7 and Figure 6.7 (continued) sho w the Normalized Throughput of SF-SA CK v ersus other W indo w-based and TFRC protocol with a bottleneck bandwidth of 60 Mbps. Belo w the Normalized Throughput graphs for each simulation are the graph with the Loss-Rate at dif ferent number of competing o ws. The increasing Loss-Rate as the number of competing o ws increases, directly reects the increasing congestion in the netw ork. 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput SF-SACK Tahoe Mean SF-SACK Mean Tahoe 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput SF-SACK Reno Mean SF-SACK Mean Reno 0 0.5 1 1.5 2 2.5 3 3.5 4 0 10 20 30 40 50 60 70 Loss Rate (%) Number of SF-SACK flows, number of Tahoe flows. 60Mb/s RED Queue 0 0.5 1 1.5 2 2.5 3 3.5 4 0 10 20 30 40 50 60 70 Loss Rate (%) Number of SF-SACK flows, number of Reno flows. 60Mb/s RED Queue Figure 6.7 Normalized Throughput and Loss-Rates of SF-SA CK Flo ws Competing with other TCP V ersions on a 60 Mbps Bottleneck Bandwidth Link 49

PAGE 59

0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput SF-SACK Newreno Mean SF-SACK Mean Newreno 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput SF-SACK Sack Mean SF-SACK Mean Sack 0 0.5 1 1.5 2 2.5 3 3.5 4 0 10 20 30 40 50 60 70 Loss Rate (%) Number of SF-SACK flows, number of Newreno flows. 60Mb/s RED Queue 0 0.5 1 1.5 2 2.5 3 3.5 4 0 10 20 30 40 50 60 70 Loss Rate (%) Number of SF-SACK flows, number of Sack flows. 60Mb/s RED Queue 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput SF-SACK TFRC Mean SF-SACK Mean TFRC 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 0 10 20 30 40 50 60 70 Loss Rate (%) Number of SF-SACK flows, number of TFRC flows. 60Mb/s RED Queue Figure 6.7 Normalized Throughput and Loss-Rates of SF-SA CK Flo ws Competing with other TCP V ersions on a 60 Mbps Bottleneck Bandwidth Link (Continued) 50

PAGE 60

As it can be seen, SF-SA CK is not friendly to the other protocols including TFRC, as it alw ays obtains more bandwidth. TFRC obtains slightly more bandwidth than other TCP protocols b ut still less amount of bandwidth than SF-SA CK. According to the concepts of aggressi v eness and responsi v eness widely used in the literature, these results sho w that the congestion mechanism of SF-SA CK is less responsi v e than the current AIMD strate gy of SA CK and also less responsi v e than TFRC. (Comparing the throughput v alues obtained by SA CK and TFRC we can see that the y are v ery close, which match v ery well with the results obtained in simulations presented in Chapter 5 as well as in [5 ]). These results were e xpected as SF-SA CK reduces its congestion windo w in a considerably less aggressi v e manner as e xplained in the Section 3.3 on W orking of SF-SA CK in Chapter 3. Ho we v er it should be noticed that if instead of SF-SA CK, a UDP source were used, UDP w ould ha v e tak en the entire bandwidth. As a result, it can be concluded that SF-SA CK is not completely f air if competing against other TCP protocols and TFRC b ut considerably f airer than UDP This is also e xpected as SF-SA CK implements the kno wn o w and congestion control mechanisms of TCP Figure 6.8 and Figure 6.8 (continued) sho w the Normalized Throughput graphs using a 15 Mbps bottleneck bandwidth link sho wing similar results. 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput SF-SACK Tahoe Mean SF-SACK Mean Tahoe 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput SF-SACK Reno Mean SF-SACK Mean Reno 0 2 4 6 8 10 12 0 10 20 30 40 50 60 70 Loss Rate (%) Number of SF-SACK flows, number of Tahoe flows. 15Mb/s RED Queue 0 1 2 3 4 5 6 7 8 9 10 0 10 20 30 40 50 60 70 Loss Rate (%) Number of SF-SACK flows, number of Reno flows. 15Mb/s RED Queue Figure 6.8 Normalized Throughput and Loss-Rates of SF-SA CK Flo ws Competing with other TCP V ersions on a 15 Mbps Bottleneck Bandwidth Link 51

PAGE 61

0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput SF-SACK Newreno Mean SF-SACK Mean Newreno 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput SF-SACK Sack Mean SF-SACK Mean Sack 0 2 4 6 8 10 12 0 10 20 30 40 50 60 70 Loss Rate (%) Number of SF-SACK flows, number of Newreno flows. 15Mb/s RED Queue 0 2 4 6 8 10 12 0 10 20 30 40 50 60 70 Loss Rate (%) Number of SF-SACK flows, number of Sack flows. 15Mb/s RED Queue 0 0.5 1 1.5 2 2.5 0 10 20 30 40 50 60 70 Normalized Throughput SF-SACK TFRC Mean SF-SACK Mean TFRC 0 2 4 6 8 10 12 0 10 20 30 40 50 60 70 Loss Rate (%) Number of SF-SACK flows, number of TFRC flows. 15Mb/s RED Queue Figure 6.8 Normalized Throughput and Loss-Rates of SF-SA CK Flo ws Competing with other TCP V ersions on a 15 Mbps Bottleneck Bandwidth Link (Continued) 52

PAGE 62

6.2.4 Friendliness of TCP UDP and SF-SA CK Flo ws It can be sho wn ho w UDP o ws competing with TCP o ws result in a highly TCP-unfriendly scenario. Figure 6.9 sho ws a UDP o w running a Constant Bit Rate (CBR) application competing with a TCP o w running a FTP application. The TCP v ersion used is TCP Sack. The CBR o w represents a video application while the FTP o w represents a data application. The bottleneck link bandwidth is set to 1 Mbps. From the Figure, the CBR rate is gradually increased from zero in steps of 0.1 Mbps and it can be seen that UDP al w ays gets its share of bandwidth, lea ving only the remaining a v ailable bandwidth for TCP This is a classic e xample of unfriendliness when UDP is used to stream video o v er the netw ork as referenced in [3 ]. 0 0.2 0.4 0.6 0.8 1 1.2 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.7 0.8 0.9 1 Average Throughput (Mbps) CBR Bit Rate (Mbps) Average Throughput : UDP:CBR vs TCP:FTP CBR FTP Available Bandwidth Figure 6.9 A v erage Throughput of a UDP Flo w Running CBR and A TCP Flo w Running FTP Application If UDP is replaced by TCP to carry video applications while competing with other TCP o ws carrying data o v er the netw ork, it is found that the TCP-Friendliness is appreciably impro v ed. As can be seen in Figure 6.10, the sources share the bandwidth in a completely f air and e xpected manner While the CBR traf c occupies a small portion of the bandwidth, the FTP application is able to grab the unused portion of the link capacity As CBR increasing its sending rate, it starts obtaining what it needs until its f air share is reached. From then, an y increase in CBR rate still results in f air share between the tw o o ws. Note that this beha vior is common to all TCP v ersions. 53

PAGE 63

0 0.2 0.4 0.6 0.8 1 1.2 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.7 0.8 0.9 1 Average Throughput (Mbps) CBR Bit Rate (Mbps) Average Throughput : TCP:CBR vs TCP:FTP CBR FTP Available Bandwidth Figure 6.10 A v erage Throughput of a TCP Flo w Running CBR and A TCP Flo w Running FTP Application The abo v e beha vior is the inspiration to de v elop TCP-based end-to-end congestion control algorithms that can be used for multimedia applications. TCP Sack is replaced with SF-SA CK to carry both audio and video traf c as sho wn in Figure 6.11. As can been seen in the graph, SF-SA CK baha v es lik e other TCP protocols in being f air when carrying data and video traf c. Hence, coupled with the properties of being smooth and friendly SF-SA CK can replace the e xisting UDP protocols for carrying multimedia traf c. 0 0.2 0.4 0.6 0.8 1 1.2 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.7 0.8 0.9 1 Average Throughput (Mbps) CBR Bit Rate (Mbps) Average Throughput : SF-SACK:CBR vs SF-SACK:FTP CBR FTP Available Bandwidth Figure 6.11 A v erage Throughput of T w o SF-SA CK Flo ws Each Running a CBR and an FTP Application 54

PAGE 64

6.2.5 F air ness of SF-SA CK F airness is another measure to sho w the amount of TCP-Friendliness e xhibited by the TCP protocol. There are se v eral w ays to measure F airness, and we use the well-kno wn F airness Inde x dened by Chiu and Jain [9 ]. The F airness Inde x measure w as e xplained in Chapter 4. Figures 6.12 and 6.13 sho w the F airness Inde x of SF-SA CK o ws competing with other W indo w-based TCP protocols as well as TFRC, at 60 Mbps and 15 Mbps bottleneck link respecti v ely 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 0 10 20 30 40 50 60 70 Fairness Index Number of Equal no. of flowtypes 1 & 2 60 Mb/s RED Queue SF-SACK-Tahoe SF-SACK-Reno SF-SACK-Newreno SF-SACK-Sack SF-SACK-TFRC Figure 6.12 F airness Inde x of SF-SA CK Flo w Competing for 60 Mbps Bottleneck Link W ith Other TCP W indo w-Based Flo ws and TFRC 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 0 10 20 30 40 50 60 70 Fairness Index Number of Equal no. of flowtypes 1 & 2 15 Mb/s RED Queue SF-SACK-Tahoe SF-SACK-Reno SF-SACK-Newreno SF-SACK-Sack SF-SACK-TFRC Figure 6.13 F airness Inde x of SF-SA CK Flo w Competing for 15 Mbps Bottleneck Link W ith Other TCP W indo w-Based Flo ws and TFRC 55

PAGE 65

From the F airness Inde x graph at 60 Mbps, it can be seen that for less number of competing o ws, e xcept for TFRC, the other protocols are closely f air with SF-SA CK. When the number of competing o ws is more than 30, all protocols baha v e f air with SF-SA CK. When comparing the results with the 15 Mbps bottleneck link, it is seen the F airness Inde x decreases as the number of competing o ws increases. This can be attrib uted to higher congestion le v els, due to increase in number of o ws and decrease in the a v ailable bandwidth at the bottleneck link. At higher congestion le v els, resulting in increase in pack et drop e v ents, SF-SA CK responds slo wly lea ving the other competing protocol to respond f aster loosing its sending rate. This leads to increasing dif ference in the transmission rates of both the class of protocols and hence decrease in F airness Inde x v alue. 6.3 P erf ormance of SF-SA CK Under Dynamic Netw ork Scenario The Dynamic Netw ork Scenario utilized here is characterized by increasing and decreasing congestion le v els in the netw ork in a short interv al of time. This is an attempt to simulate real netw ork conditions b ut still cannot represent the real w orld Internet through simulations. The topology for the Dynamic Netw ork Scenario w as e xplained in detail in Chapter 4. The Long-T erm and ShortT erm F airness performance of SF-SA CK are sho wn in the follo wing sections. 6.3.1 Long-T erm F air ness of SF-SA CK The Long-T erm F airness of SF-SA CK competing with other protocols in a rapidly changing netw ork scenario is studied here, where the a v ailable bandwidth is increased and decreased in short interv als. Figure 6.14 sho ws the Normalized Throughput v ersus the length of ON/OFF time period. The X-axis sho ws the combined length of ON/OFF time period of CBR source and Y -axis, the Normalized Throughput. From the graphs, it is observ ed that all protocols e xhibit f airness with SF-SA CK when the period of CBR source is lo w When the time period of CBR source is be yond 1 sec, we see unf airness among the o ws. This is because, when the period of netw ork v ariation is less, the losses occuring to TCP protocols reduce their sending rate drastically while SF-SA CK reduces its sending rate slo wly The lesser responsi v eness of SF-SA CK also e xplains why in o v erall it recei v es more throughput than 56

PAGE 66

0 0.2 0.4 0.6 0.8 1 1.2 1.4 0.01 0.1 1 10 100 Normalized Bandwidth Length of high/low bw (15Mb/5Mb) period Competing SF-SACK and Tahoe flows SF-SACK Tahoe 0 0.2 0.4 0.6 0.8 1 1.2 1.4 0.01 0.1 1 10 100 Normalized Bandwidth Length of high/low bw (15Mb/5Mb) period Competing SF-SACK and Reno flows SF-SACK Reno 0 0.2 0.4 0.6 0.8 1 1.2 1.4 0.01 0.1 1 10 100 Normalized Bandwidth Length of high/low bw (15Mb/5Mb) period Competing SF-SACK and NewReno flows SF-SACK NewReno 0 0.2 0.4 0.6 0.8 1 1.2 1.4 0.01 0.1 1 10 100 Normalized Bandwidth Length of high/low bw (15Mb/5Mb) period Competing SF-SACK and Sack flows SF-SACK Sack 0 0.2 0.4 0.6 0.8 1 1.2 1.4 0.01 0.1 1 10 100 Normalized Bandwidth Length of high/low bw (15Mb/5Mb) period Competing SF-SACK and TFRC flows SF-SACK TFRC Figure 6.14 Long T erm F airness of SF-SA CK Flo ws Competing W ith Other TCP Protocols Under Dynamic Netw ork Scenario others e v en in v arying netw ork conditions. In general, it is observ ed that the o v erall link utilization is high with all the protocols. 6.3.2 Short-T erm F air ness of SF-SA CK Short-T erm or T ransient F airness is measured using the topology as e xplained in Chapter 4. T able 6.3 sho ws the con v er gence times of SF-SA CK and other TCP protocols in seconds. The v alues are the a v erage con v er gence times of 10 simulation runs with 95% condence interv al. Among the W indo w-based TCP protocols, SF-SA CK tak es the maximum time to con v er ge and this is because of its responsi v e nature, while ha ving the same aggresi v eness as others, since the increase algorithm 57

PAGE 67

is still the same. As e xpected, the con v er gence time of TFRC is considerably higher than SF-SA CK due to its less aggressi v eness as seen in pre vious simulations. T able 6.3 Con v er gence T imes (In Seconds) of SF-SA CK and Other Protocols Protocol Con v er gence T ime TCP T ahoe E#Q]$#( TCP Reno #Q]$#(( TCP Ne w Reno E#&gq$# ‹ V TCP Sack #šˆ]$#& ‹ SF-SA CK # {# ‹ TFRC &¦#Q]E# ‹ 58

PAGE 68

CHAPTER 7 CONCLUSION AND FUTURE W ORK This thesis presents SF-SA CK, a Smooth Friendly TCP SA CK-based transport layer protocol for streaming applications. SF-SA CK calculates the congestion windo w v ariable using a lo w pass lter to pro vide a smooth transfer rate more suitable for these types of applications. Using simulations, it is sho wn that SF-SA CK of fers se v eral adv antages o v er TFRC. First, SF-SA CK pro vides transfer rates considerably smoother than TCP b ut only slightly w orse than TFRC. Second, SFSA CK is considerably f airer than UDP when competing against TCP and completely f air when both streaming and data-oriented applications use it to share the bottleneck link. Third, it is simpler to implement and understand than TFRC, and fourth, it only requires sender side modications. The current and future w ork contemplates se v eral aspects. First, it needs to be v eried that TCP-Friendliness still holds when SF-SA CK connections ha ving dif ferent R TTs compete with each other In addition, the sender side can be modied further to accommodate streaming applications better and to eliminate the w astage of resources that implies retransmission of real-time pack ets lost since the y are not useful an ymore when the y nally reach the destination. The ef fect of Explicit Congestion Notication (ECN) bit on the smoothness and friendliness of SF-SA CK o ws need to be studied. It w ould be interesting to study the beha vior of SF-SA CK for multicasting netw orks where the pack ets may be broadcasted as in multimedia applications. Simulations using a dif ferent and more comple x topologies w ould help understand the protocols interaction well. One idea w ould be to simulate the dynamic netw ork scenario using CBR o ws forming range of patterns lik e sawtooth and r e ver se sawtooth 59

PAGE 69

REFERENCES [1] V Jacobson, “Congestion A v oidance and Control, ” in Symposium on Communications Ar c hitectur e and Pr otocols (SIGCOMM) Stanford, CA, Aug. 1988, pp. 314–329. [2] J. Postel, “User Datagram Protocol, RFC 768, ” http://www .ietf .or g/rfc/rfc768 .txt Aug. 1980. [3] S. Flo yd and K. F all, “Promoting the Use of End-to-End Congestion Control in the Internet, ” IEEE/A CM T r ansactions on Networking v ol. 7, no. 4, pp. 458–472, 1999. [4] G. Chatranon, M. A. Labrador and S. Banerjee, “A Surv e y on TCP-friendly Router -based A QM Schemes, ” Submitted to Computer Communications, A vailable at: http://www .csee .usf .edu/ labr ador Dec. 2003. [5] S. Flo yd, M. Handle y J. P adhye, and J. W idmer “Equation Based Congestion Control for Unicast Applications, ” in Pr oceedings of A CM SIGCOMM 2000 Aug. 2000, pp. 43–56. [6] R. Rejaie, M. Handle y and D. Estrin, “RAP: An End-to-end Rate-based Congestion Control Mechanism for Realtime Streams in the Internet, ” in Pr oceedings of IEEE INFOCOM '99 Ne w Y ork, NY Mar 1999. [7] J. Nagle, Cong estion Contr ol in IP/TCP Internetworks, RFC 896 Jan. 1984. [8] J. Postel, “T ransmission Control Protocol, RFC 793, ” http://www .ietf .or g/rfc/rfc793 .txt Sept. 1981. [9] D. Chiu and R. Jain, “Analysis of the Increase/Decrease Algorithms for Congestion A v oidance in Computer Netw orks, ” J ournal of Computer Networks and ISDN Systems v ol. 17, no. 1, pp. 1–14, June 1989. [10] V Jacobson, “Modied TCP Congestion A v oidance Algorithm, ” T ec hnical Report Apr 1990. [11] S.Flo yd and T .Henderson, “The Ne wReno Modication to TCP' s F ast Reco v ery Algorithm, RFC 2582, ” http://www .ietf .or g/rfc/rfc2582 .txt Apr 1999. [12] M. Mathis, J. Mahda vi, S.Flo yd, and A. Romano w “TCP Selecti v e Ackno wledgment Options, RFC 2018, ” http://www .ietf .or g/rfc/rfc2018 .txt Oct. 1996. [13] K. F all and S. Flo yd, “Simulation-based Comparisons of T ahoe, Reno, and SA CK TCP, ” in A CM SIGCOMM Computer Communication Re vie w Jul. 1996, v ol. 26, pp. 5–21. [14] M. Smith and K. K. Ramakrishnan, “F ormal V erication of Safety and Performance Properties of TCP Selecti v e Ackno wledgment, ” in Pr oceedings of International Confer ence on Network Pr otocols Austin, TX, Oct. 1998, p. 227. 60

PAGE 70

[15] L.S. Brakmo and L.L. Peterson, “TCP V e gas: End to End Congestion A v oidance in a Global Internet, ” IEEE J ournal on Selected Ar eas in Communications v ol. 13, No.8, pp. 1465–80, Oct. 1995. [16] L.S. Brakmo, S.W O'Malle y and L.L. Peterson, “TCP V e gas: Ne w T echniques for Congestion Detection and A v oidance, ” A CM SIGCOMM Confer ence v ol. 13, No.8, pp. 24–35, May 1994. [17] Y .R. Y ang and S.S. Lam, “General AIMD Congestion Control, ” in Pr oceedings of the 8th International Confer ence on Network Pr otocols Osaka, Japan, No v 2000, pp. 187–198. [18] S. Flo yd and V Jacobson, “Random Early Detection Gate w ays for Congestion A v oidance, ” IEEE/A CM T r ansactions on Networking v ol. 1, no. 4, pp. 397–413, Aug. 1993. [19] D. Bansal and H. Balakrishnan, “Binomial Congestion Control Algorithms, ” in Pr oceedings of the Confer ence on Computer Communications Anchroage, AK, Apr 2001, pp. 631–640. [20] K. Chandrayana and S. Kalyanaraman B. Sikdar “Comparati v e Study of TCP Compatible Binomial Congestion Control Schemes, ” in IEEE W orkshop on High P erformance Switc hing and Routing: Mer ging Optical and IP T ec hnolo gies Osaka, Japan, May 2002, pp. 224–228. [21] M. Gerla, M. Y Sanadidi, R. W ang, A. Zanella, C. Casetti, and S. Mascolo, “TCP W estw ood: Congestion W indo w Control Using Bandwidth Estimation, ” in Pr oceedings of IEEE Globecom 2001 San Antonio, T e xas, USA, No v 2001, v ol. 3, pp. 1698–1702. [22] C. Casetti, M. Gerla, S. Mascolo, M. Y Sanadidi, and R. W ang, “TCP W estw ood: Bandwidth Estimation for Enhanced T ransport o v er W ireless Links, ” in Pr oceedings of A CM Mobicom 2001 Rome, Italy July 2001, pp. 287–297. [23] M. Handle y S. Flo yd, J. P adhye, and J. W idmer “TCP Friendly Rate Control (TFRC): Protocol Specication, RFC 3448, ” http://www .ietf .or g/rfc/rfc3448 .txt Jan. 2003. [24] S. Flo yd, M. Handle y and J. P adhye, “A Comparison of Equation-Based and AIMD Congestion Control, ” in http://www .aciri.or g/tfr c/ May 2000. [25] D. Bansal, H. Balakrishnan, S. Flo yd, and S. Shenk er “Dynamic Beha vior of Slo wlyResponsi v e Congestion Control Algorithms, ” in Pr oceedings of the 2001 Confer ence on Applications, T ec hnolo gies, Ar c hitectur es, and Pr otocols for Computer Communications (SIGCOMM'01) San Die go, California, USA, Aug. 2001, pp. 263–274. [26] S. Baktha v achalu and M. A. Labrador “TFRC Friendliness and the Case of ECN, ” International J ournal of Communication Systems (submitted) Sept. 2003. [27] S. Flo yd, “TCP and Explicit Congestion Notication, ” A CM Computer Communication Revie w v ol. 24, no. 5, pp. 10–23, Oct. 1994. [28] K. J. Astrom and B. W ittenmark, Computer -Contr olled Systems: Theory and Design Prentice Hall Inc., Engle w ood Clif fs, N.J., USA, 1984. [29] H. Nyquist, “Certain topics in tele graph transmission theory, ” T r ansactions AIEE v ol. 47, pp. 617–644, Apr 1928. [30] Information Sciences Institute, USC, http://www .isi.edu/nsnam/ns/, ns-2 Network Simulator 2000. 61

PAGE 71

[31] S. Flo yd, Recommendation on using the g entle variant of RED Mar 2000. [32] ns-2 F ix to V e gas Response to ECN P ac k ets http://mailman.isi.edu/pipe rmail/ ns -us ers /20 01 July/016514.html, 2001. 62