(1)
The authors are in search of a reliable, congestion control, real-time media traffic supportable protocol which is not yet available. Previously, for this purpose the authors were taking help of Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). TCP is a reliable, congestion control protocol which works fine for low bandwidth scenarios and UDP is an unreliable protocol but works fine in high bandwidth scenarios. A protocol that opts in both situations high and low bandwidth scenarios is required. One such a protocol TCP Friendly Rate Control (TFRC) is designed by Internet Engineering Task Force People (IETF) and it is a reliable, congestion control protocol. TFRC is a rate based approach and well suitable for real-time video traffic because of smooth sending rate and friendliness with TCP flows achieved in it. This paper shows the complete study of TFRC, and performance of TFRC is compared with TCP flows such as TCP SACK, TCP Vegas, TCP Reno, and TCP Tahoe and also with UDP in wired environment.
The authors are in search of a reliable, congestion control, real-time media traffic supportable protocol without losing its fair share of bandwidth over Internet. The present Internet infrastructure only provides best-effort service for non-real time traffic. Most of the major traffics of today's Internet are covered by real-time streaming media applications such as video on demand, game playing, video conferencing systems, etc. So this much of heavy video traffic on Internet is causing congestion collapse [1].
Transmission Control Protocol (TCP) [2] is a reliable and congestion control [10] protocol but at higher rates it won't show its effectiveness. TCP Congestion Control [20] mechanism reduces the sending rate by half in response to even a single packet drop. It shows unwanted aggressiveness when congestion occurs which multimedia applications doesn't want. To avoid [17] this situation different variations of TCP were proposed for congestion control such as TCP-SACK [3], TCP-Vegas [4], TCP-Reno [5], and TCP-Tahoe [6] etc. All of these try to modify the Additive Increase Multiplicative Decrease (AIMD) [16], [19] strategy to improve TCP performance. TCP was not primarily designed to support streaming media traffic, the saw-tooth behavior of TCP effects the perceived video quality. So, TCP need more improvements to support congestion control [18] for realtime streaming media traffic.
User Datagram Protocol (UDP) [7] is selected for data transfer in higher rates even though it is unreliable. UDP doesn't support any congestion control mechanism which can lead to instability in the network. To solve all these problems a new protocol is designed by Internet Engineering Task Force (IETF) called TCP Friendly Rate Control (TFRC). It is a reliable protocol for streaming applications and also it supports congestion control mechanism very effectively. It is an equation based approach rather than window based.
Section 2 describes TFRC mechanisms, section 3 describes the performance metrics that are used to evaluate TFRC, section 4 presents the simulation environment, section 5 presents the Results and Analysis of TFRC [8] with other TCP Flows and UDP.
It is a simple modification of TCP protocol, which includes a Fast Retransmit mechanism. In Tahoe, triple duplicate Acknowledgements (ACKs) are treated as the same as a time out, and then Tahoe will perform Fast Retransmit. In Fast Retransmit, the slow start threshold set of half of the current window size, reduces the congestion window to 1 Maximum Segment Size (MSS), and it will reset to slow-start state.
By adding an additional functionality to TCP-Tahoe, TCPReno was developed. Here along with Fast Retransmit, Fast Recovery was also added. In this mechanism, if three duplicate ACKs are received, TCP-Reno will halve the Congestion Window (CWND) instead of setting it to one Maximum Segment Size (MSS) like Tahoe and sets slow start threshold to the new congestion window, and performs a Fast Retransmit Phase and enters into a phase called Fast Recovery Phase. If an Acknowledgement times out, slow start phase is used as it is with Tahoe.
In Fast Recovery phase, Traditional TCP retransmits the missing packet that was specified by three duplicate Acknowledges, and wait for an ACK of the whole transmit window before returning to congestion avoidance phase. If there is no ACK, TCP-Reno experience a time out and enters the slow start state.
Until the mid-1990s, all of the TCP's set time outs and measured Round Trip Delays (RTDs) were purely based on only the last sent packet in the transmit buffer. But in TCP Vegas time outs were set and RTDs were measured for each and every packet in the transmit buffer. And also, TCP Vegas applies Additive Increases (AI) approach in the Congestion Window (CWND).
TCP SACK (Selective Acknowledgements) [3] is a little bit modification of TCP Reno. It can solve some of the problems faced by TCP Reno such as identifying multiple lost packets and reducing unnecessary re-transmissions. SACK preserves the slow-start and fast retransmit parts of Reno. In SACK approach segments are acknowledged selectively not cumulatively. So, each acknowledgement has a separate block that says which segments are acknowledged. So, in this way the sender will identify the segments that have been acknowledged and segments which are still outstanding.
Whenever, the sender comes into fast recovery then SACK creates and initializes a variable type pipe. This is used to estimate amount of data which is outstanding in the network buffer, and also sets congestion window to half the current congestion window size. Every time it receives an ACK it decreases the pipe by one and each and every time it resends a segment it raises to one more of it. Whenever, the pipe goes smaller than the CWND examines which segments are not received or dropped, and sends them only. If there are no such outstanding segments then it sends a packet that is new. So, more than one segment that is lost can be sent in one Round Trip Time (RTT).
TFRC [12], [13] is a rate based, congestion control, reliable and end-to-end protocol to suite multimedia applications. TFRC is more suitable for real-time streaming data because of smooth sending rate achieved by it. TFRC is capable of dynamically adjusting next sending rate at the sender side as congestion occurs. The equation [11], [14] used by TFRC is shown in equation 1.
‘X’ is the sending rate in bytes/seconds
‘s’ is the segment size in bytes
‘RTT’ is the round trip time in seconds
‘b’ indicates the number of packets acknowledged by a single Acknowledgement
‘p’ is the loss event rate (between 0 and 1)
‘RTO’ indicates the retransmission time-out in seconds (4RTT).
In Figure 1, the Algorithm says TFRC is a receiver driven mechanism. Because all the congestion control data is calculated as packet loss event rate (p) [21] at the receiver rather in the sender. The receiver must continuously maintain and update the loss event history data structure and continuously process the loss event rate (p) and send it back to the sender as soon as it observes an increase in the loss event rate as a feedback.
Figure 1. Simple Network Dumbbell Topology
The algorithm used at the receiver side is Receive Packet Method and Feedback Method.
1. Add each packet to packet history data structure
2. Assign p_updated to new value of packet loss rate
3. If p_updated greater than p_old then expire the feedback timer and call create feedback method.
1. Compute average packet loss rate
2. Calculate measured receive rate
3. Prepare and send feedback packet
4. Restart feedback timer
The End-to-End Delay is defined as the average delay of all the packets while travelling from source node to the destination node.
The Packet Loss Ratio is defined as the ratio of number of lost packets to the sum of number of packets received and number of lost packets.
The Packet Delivery Ratio is defined as the ratio of total number of packets successfully received by the destination nodes to the number of packets sent by the source nodes.
The performance of the proposed TFRC is evaluated using the network simulator version ns-2.35 [9], [15], and the simulation results are compared with all other TCP variants and UDP. The network topology used in this paper is a simple network dumbbell topology as shown in Figure 1.
Figure 2 shows, a simple network topology consisting of six source nodes and six destination nodes. The access link capacities were 2 Mbps and the bottleneck capacity between nodes R0 and R1 is also 2 Mbps. The access links delay was 0.002 seconds.
Figure 2. End-to-End Delay of TFRC, UDP and TCP Variants
In this paper, the authors compared the performance of TCP-Tahoe, TCP-Reno, TCP-Vegas, TCP-SACK, TFRC and UDP through Packet Delivery Ratio, Packet Loss Ratio, End-to- End Delay.
Figure 2, shows that the end-to-end delay of TFRC is equal to TCP flows up to 4 Mbps, later compared to UDP, TFRC gives far better results. The end-to-end delay of TFRC is less than UDP. The end-to-end delay of TCP SACK is second best protocol in all TCP flows. TCP-Tahoe and Reno are giving least results. Here, the authors increased the UDP rate and the TFRC rate simultaneously and also changed TCP window sizes for all other TCP flows. The reason why TFRC has better end-to-end delay is its dynamically adjusting next sending rate behaviour and there is no need to wait for feedback of each packet. Whenever, packet loss occurs then only it waits for feedback and adjusts its next sending rate without loosing its fair share of bandwidth.
Figure 3, shows that the packet loss ratio of TFRC is almost friendly with TCP flows upto 4 Mbps, later compared to UDP, TFRC has low packet loss ratio. The packet loss ratio of TCP SACK is second best protocol in all TCP flows. TCP Tahoe and Reno are giving least results. Here, the authors increased UDP rate and TFRC rate simultaneously and also changed TCP window sizes for all other TCP flows. Here, the packet loss ratio of TFRC is far better than UDP because at higher rates also TFRC preserves reliability with low end-to- end delay.
Figure 3. Packet Loss Ratio of TFRC, UDP and TCP Variants
Figure 4, shows that the Packet Delivery Ratio of TFRC is almost friendly with TCP flows upto 4 Mbps, later compared to UDP, TFRC has good packet delivery ratio. The packet loss ratio of TCP Vegas is the second best protocol in all TCP flows. TCP SACK and Reno are giving least results. Here, the authors increased UDP rate and TFRC rate simultaneously and also changed TCP window sizes for all other TCP flows. The packet delivery ratio of TFRC is very good because it always follows the TCP flows at normal rates. TCP has good packet delivery ratio and also when compared to UDP at higher rates because of its congestion control mechanism. TFRC has good packet delivery ratio.
Figure 4. Packet Delivery Ratio of TFRC, UDP and TCP Variants
By considering all the above results the authors have said that TFRC is performing well for video traffic and it can be replaced with both TCP and UDP at higher bandwidth situations. The Packet Delivery Ratio is same as TCP at normal rates which is a good sign and very good when compared to UDP at higher rates. The Packet Loss Ratio is getting almost same results as TCP Flows at lower rates and good compared to UDP which is an unreliable protocol. The End-to-End Delay is very good when compared to TCP flows which are having high delays at higher rates. So, by observing above all the authors have said that TFRC is well suitable for real-time media traffic.
In future, by shifting the overall receiver functionality like calculating packet loss ratio to sender, the performance of TFRC can be improved by reducing additional load on receiver and the delay for receiving feedback from receiver can be reduced.