| Author: | Tsang, Chi-man Estella |
| Title: | A simulation study on the fairness of TCP Vegas |
| Degree: | M.Sc. |
| Year: | 2001 |
| Subject: | TCP/IP (Computer network protocol) Hong Kong Polytechnic University -- Dissertations |
| Department: | Multi-disciplinary Studies Department of Computing |
| Pages: | x, 149 leaves : ill. ; 30 cm |
| Language: | English |
| Abstract: | In addition to throughput, fairness is another important performance criteria of TCP protocols. Fairness is especially important for best effort service, which is still the dominant type of service in the Internet and, predictably, in the years to come. However, the TCP protocols prevailing in the Internet, including TCP Tahoe and TCP Reno, are known to be unfair, especially to connections with larger round-trip delays. Using ns simulator, I have examined the fairness of TCP Vegas with focus on 4 issues : 1) Is TCP Vegas really fair to connections with larger propagation delays, 2) what is the impact of the thresholds 帢, and 帣 , used in TCP Vegas' congestion avoidance algorithm on fairness, 3) how fair TCP Vegas is when there are many active flows, and 4) does the receiver acknowledgement strategy, namely immediate and delayed acknowledgement, which affects the estimation of the round-trip times, affect the fairness of TCP Vegas ? For question 1, the simulation results support that, when 帢=-1 and 帣=3, TCP Vegas is still unfair to connections with larger propagation delays but, unlike TCP Reno, the delay bias does not necessarily increase as the delay differences increases. However, if 帢=1 and 帣=3, the fairness of TCP Vegas is not necessarily better than that of TCP Reno. The unfairness problem can be resolved by Enhanced TCP Vegas that sets 帢=帣=2 or 3 but NOT 1. For question 2, I find that, the fairness is consistently good when 帢=帣=2 or 3. When 帢=帣=1, the fairness is unstable and may be worse than that when 帢=1 and 帣=3. Considering a trade-off among fairness, stability and aggressiveness, a value of 3 seems to be an acceptably good choice. For question 3, when there are many active flows, all of which are running either TCP Reno or TCP Vegas, the fairness of TCP Reno is better and more stable than that of TCP Vegas. The contrary occurs when the number of flows times the threshold of Enhanced TCP Vegas is less than the RED minimum threshold. Intuitively, this suggests that the fairness of TCP Vegas is better when there are few or no retransmissions or timeouts. The result is obtained after amending the ns code to eliminate 2 causes of deadlock that occur after a Reno-type timeout. Moreover, the fairness of TCP Vegas host-only configuration improves when the RED thresholds are higher. The percentage improvement, however, diminishes when the number of flows is large enough. When there are many active flows with a mixture of TCP Vegas and TCP Reno, the fairness tends to deteriorate as the number of active flows increases. When the RED thresholds are low, TCP Vegas connections are able to capture higher goodput on average. When the RED thresholds are high and the number of flows is low, TCP Reno is the beneficiary. Intuitively, this suggests that TCP Reno performs better when the RED thresholds allow a long enough queue. Moreover, the variance in goodputs within the Vegas community is larger than that within the Reno community. Therefore, while the difference in the average goodput between the Vegas community and the Reno community contributes to unfairness, the difference in goodputs within the Vegas community also contributes significantly. This is due to the record of an under-estimated minimum round-trip time after a Reno-type timeout, causing some connections to run at very low throughputs throughout the rest of the simulation time. Hence, the variance of goodputs within the Vegas community is poor. The findings suggest possible incompatibility between the Reno-type timeout subroutine and the Vegas algorithms. Besides, TCP Vegas may perform, unnecessary re-transmission after a Reno-type timeout. For question 4, I find that fairness does not deteriorate when all the receivers adopt the delayed acknowledgement strategy rather than the immediate acknowledgement strategy. In general, the delayed acknowledgment strategy delays the detection of a proper minimum round-trip time. The first estimation of the minimum round-trip time is always over-estimated However, since 2 back-to-back TCP segments are sent when the congestion window increases to 2, the receiver returns an acknowledgement nearly immediately after the first of these 2 segments have been received. Therefore, TCP Vegas can eventually capture a minimum round-trip time that is much closer to the true value. Finally, when the receiver adopts the delayed acknowledgement strategy, the calculated expected rate may even be smaller than the actual sending rate. |
| Rights: | All rights reserved |
| Access: | restricted access |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| b15996001.pdf | For All Users (off-campus access for PolyU Staff & Students only) | 5.28 MB | Adobe PDF | View/Open |
Copyright Undertaking
As a bona fide Library user, I declare that:
- I will abide by the rules and legal ordinances governing copyright regarding the use of the Database.
- I will use the Database for the purpose of my research or private study only and not for circulation or further reproduction or any other purpose.
- I agree to indemnify and hold the University harmless from and against any loss, damage, cost, liability or expenses arising from copyright infringement or unauthorized usage.
By downloading any item(s) listed above, you acknowledge that you have read and understood the copyright undertaking as stated above, and agree to be bound by all of its terms.
Please use this identifier to cite or link to this item:
https://theses.lib.polyu.edu.hk/handle/200/4607