Studying Fairness of TCP Variants and UDP Traffic

Transcription

1 Studying Fairness of TCP Variants and UDP Traffic Election Reddy B.Krishna Chaitanya Problem Definition: To study the fairness of TCP variants and UDP, when sharing a common link. To do so we conduct various experiments with different scenarios where in we measure parameters like throughput, congestion window (CWND) and round trip time (RTT) delay. Setups, Parameters, Evaluation and Results: We have conducted experiments with three different scenarios. We have tested each scenario with different setups to observe the fairness/unfairness of TCP Tahoe, TCP Reno, TCP NewReno, TCP Sack and UDP. The parameters taken into account are throughput, congestion window and roundtrip time. Scenario1: S D1 shared (router)r1 # # R2 (router) link S D2 The scenario is run with different setups each with different combinations of TCP variant and UDP flows. Some of the experiments and their results are shown below: Case 1: The parameters for this case are: Link Bandwidth Delay s1 r1 2Mbps 10ms s2 r1 2Mbps 10ms r1 r2 1Mbps 20ms d1 r2 2Mbps 10ms d2 r2 2Mbps 10ms The queue limit for the link r1 r2 is 10 packets.

2 For the above parameters, we conducted the following experiments and plotted graphs for throughput, congestion window and round trip time (RTT). 1. S1 D1 flow as a Tahoe flow and S2 D2 flow as a UDP flow Observations: The UDP flow completely dominated the Tahoe flow. The throughput of the Tahoe flow is decreased rapidly as the UDP flow started. As UDP flow started, packets started dropping at the queue, timeout occured at sender S1 and finally the congestion window is brought down to 1. The round trip time graph is constantly increasing as there is lot of congestion at the intermediate routers R1 and R2. 2. S1 D1 flow as a Reno flow and S2 D2 flow as a UDP flow. Observations: The throughput in this case is similar to that of Tahoe UDP case. The congestion window in this case recoverd from the timeout faster than Tahoe as Reno has Fast recovery mechanism. The RTT in this case is better than that of Tahoe case. 3. S1 D1 flow as a NewReno flow and S2 D2 flow as a UDP flow. Observations: The throughput and average congestion window size of NewReno are more than that of Reno and Tahoe. The RTT graph in this case is similar to that of Reno. 4. S1 D1 flow as a SACK flow and S2 D2 flow as a UDP flow. Observations: SACK throughput graph is similar to that of Tahoe, it is less than that of NewReno. Congestion window graph is similar to that of NewReno. Roundtriptime on this case is more than that of NewReno. So NewReno performance is better than all other TCP varients when they run in conjunction with UDP. 5. S1 D1 flow as a Tahoe flow and S2 D2 flow as a Reno flow. Observations: As expected, Reno performs better than Tahoe. The throughput, congestion window and RTT in case of reno are better than that of Tahoe. These can be observed clearly from the graphs.

3 6. S1 D1 flow as a Reno flow and S2 D2 flow as a NewReno flow. Observations: The throughput, congestion window and RTT graphs for both Reno and NewReno are almost similar except that NewReno performed well in throughput and congestion window. 7. S1 D1 flow as a Tahoe flow and S2 D2 flow as a SACK flow. Observations: We observed that SACK performed well in throughput, congestion and RTT graphs. To observe more difference we plotted graphs in this case for a queue size of 5 packets at Router2. Graph for throughput for this case is shown below: In the above graph, the green colored line indicates throughput for SACK and the red colored line indicates throughput for Tahoe.

4 Case 2: The parameters for this case are: Link Bandwidth Delay s1 r1 2Mbps 10ms s2 r1 2Mbps 10ms r1 r2 2Mbps 10ms d1 r2 2Mbps 10ms d2 r2 2Mbps 10ms The queue limit for the link r1 r2 is 20 packets. For the above parameters, we conducted the following experiments and plotted graphs for throughput, congestion window and round trip time (RTT). 1. S1 D1 flow as a Tahoe flow and S2 D2 flow as a UDP flow 2. S1 D1 flow as a Reno flow and S2 D2 flow as a UDP flow. 3. S1 D1 flow as a NewReno flow and S2 D2 flow as a UDP flow. 4. S1 D1 flow as a SACK flow and S2 D2 flow as a UDP flow. Observations: Here we increased the queue size to 20 packets at router 2. So the packet drop decreased and hence throughput for all the TCP variants increased when compared to that of queue size 10. An increase in average CWND is also observed. Even the RTT delay in the case with higher queue size is low when compared to RTT delay in the case with lower queue size. 5. S1 D1 flow as a Tahoe flow and S2 D2 flow as a Reno flow. 6. S1 D1 flow as a Reno flow and S2 D2 flow as a NewReno flow. 7. S1 D1 flow as a Tahoe flow and S2 D2 flow as a SACK flow. Observations: In case of Reno and Tahoe, Reno performed well with respect to all characteristics. Throughput, average CWND and average RTT in case of Reno are better than those of Tahoe. The results for Reno and NewReno experiment are almost similar for all the three characteristics. In case of SACK vs Tahoe, SACK performed well. A sample

5 graph for SACK Tahoe CWND experiment is shown below. This shows the clear difference between the two variants. In the above graph green colored line shows the CWND for SACK and red colored line shows CWND for Tahoe. It can be clearly observed that average CWND for SACK is greater than that of Tahoe. Case 3: The parameters for this case are: Link Bandwidth Delay s1 r1 2Mbps 10ms s2 r1 2Mbps 10ms r1 r2 2Mbps 10ms d1 r2 2Mbps 10ms d2 r2 2Mbps 10ms The queue limit for the link r1 r2 is 30 packets. For the above parameters, we conducted the following experiments and plotted graphs for throughput, congestion window and round trip time (RTT).

6 1. S1 D1 flow as a Tahoe flow and S2 D2 flow as a Reno flow. 2. S1 D1 flow as a Reno flow and S2 D2 flow as a NewReno flow. 3. S1 D1 flow as a Tahoe flow and S2 D2 flow as a SACK flow. Observations : The throughput, average CWND and average RTT delay for all the above cases are observed to be similar. As queue size is increased to 30 packets at the routers, no packet drop is observed and hence all the TCP variants behaved similarly. The graph for RTT SACK and Tahoe in this case is shown below: Effect of Random Early Detection(RED) : All the above experiments are performed using DropTail Queue mechanism. We observed that no considerable amount of increase is found in throughput or CWND by using RED mechanism over Drop Tail method. The reason for this behaviour could be that RED does congestion avoidance so as to avoid congestion in the network. So due to this it might drop many packets and thus reduces the overall throughput and CWND.

7 Scenario 2: S1 D1 \ / \ / S-Sender D R R S2 D-Destination / \ R-Router / \ D3 S3 The main aim of this scenario is to observe whether the reverse traffic has severe effect on the acknowledgements of a the current flow. S1 D1 is considered to be our current flow and reverse traffic is due to the flows S2 D2 and S3 D3. The parameters for this experiment are: Link Bandwidth Delay s1 r1 2Mbps 10ms s2 r2 2Mbps 10ms s3 r2 2Mbps 10ms r1 r2 1Mbps 20ms d1 r2 2Mbps 10ms d2 r1 2Mbps 10ms d3 r1 2Mbps 10ms The queue limit for the links r1 r2 and r2 r1is 10 packets each. Observations: The effect of reverse traffic on S1 D1 flow is that few acknowledgements of this flow are lost at router R2 leading to timeouts for some packets. So throughput of the flow S1 D1 is decreased. But the throughput of the flow S3 D3 is much less than that of the flow S1 D1. This is due to loss of packets at router R2 and also due to sharing of bottleneck link with the flow S2 D2.

8 Scenario 3: S1 S2 S3 S4 S5 S - SENDERS D - DESTINATION R - ROUTERS R1 R2 R3 R4 R5 D The parameters for this case are Link Bandwidth Delay s1 r1 2Mbps 10ms s2 r1 2Mbps 10ms s3 r3 2Mbps 10ms s4 r4 2Mbps 10ms s5 r5 2Mbps 10ms r1 r2 1Mbps 20ms r2 r3 1Mbps 20ms r3 r4 1Mbps 20ms r4 r5 1Mbps 20ms r5 d 2Mbps 10ms The queue sizes at the links are : s1 r1 >10 s2 r2 >10 s3 r3 >10

9 s4 r4 >10 s5 r5 >10 r1 r2 >20 r2 r3 >20 r3 r4 >20 r4 r5 >20 r5 d >10 1. Same TCP variant for all flows. a) All flows are of type Tahoe b) All flows are of type Reno c) All flows are of type NewReno d) All flows are of type SACK Observations : In all the above cases, the throughput for S5 flow is better than all other flows. As packets from all other sources have to pass through more than one bottleneck links, the throughput for those flows is less when compared to that with S5. Similarly the RTT delay for packets that belong to S5 is less than that of all other sources. So the flows which need to cross less number of bottleneck links will perform better. A sample graph for this experiment is shown below. All the flows here are of NewReno type.

10 2. all flows are of different type. a) UDP is nearest and Tahoe is farter from destination s1 d > Tahoe s2 d > Reno s3 d > NewReno s4 d > SACK s5 d > UDP

11 b) UDP is farthest and Tahoe is nearer to destination s1 d > UDP s2 d > SACK s3 d > NewReno s4 d > Reno s5 d > Tahoe Observations : In case (a), throughput and CWND for all the flows decrease as we move farther from the destination, irrespictive of the type of TCP variant used. But in case (b) though SACK is placed farther from destination, it performed well when compared to Reno and NewReno as shown in below graph. In the below shown graph, the red,green, violet, pink,blue colored lines show throughput for UDP, SACK, NewReno, Reno and Tahoe respectively.

12 Conclusion: Thus we can conclude the following about the TCP variants and UDP from our experiments. SACK performs well when compared to all other TCP variants. It is also oberved that SACK performs well even when it is at more distance(more number of bottleneck links and queues in the path) from the destination when compared to other TCP variants which are very near (less number of bottleneck links and queues in the path) to the destination. Performance of TCP Reno and TCP NewReno is similar to a large extent but less than that of SACK and better than that of TCP Tahoe. TCP Tahoe is performing worse when compared to all other TCP variants. UDP traffic when present is occupying the link to the large extent and thus leading to poor performance of any other TCP variant. Reverse Traffic is having a small impact on the TCP traffic. The acknowledgements of the TCP flow are lost due to heavy reverse traffic and hence reduction in performance. Both RED and Drop Tail queuing mechanisms perform similarly when compared for throughput, CWND and RTT delay.