One of the most important parameter of data communication is the TCP protocol. It has underwent many changes which brought into existence many variant of it like tahoe, reno, new reno, sack, vegas, westwood. Nowadays we are using TCP SACK as the tcp variant as it is better as compared to its predecessor reno. With the software NIST Net we could emulate any kind of links and get the results with actual packets in consideration. The procedure of testing any network related protocol is first simulated and if the results are satisfactory than the emulation is done which is in actual a real test bed so if the output are satisfactory then it is directly used as a part of existing network. With Linux as the operating system installed in three computers and one of them acting as a router which has NIST Net installed in it; we could generate the all the parameter that need to be considered in data communication. We can change the bandwidth, delay, drop rate with respect to congestion etc so that we could consider the parameters of actual links that will be involved and can get the idea of the throughput with the system and hence we could get the idea of the output. All new protocols go through this testing procedure before getting into implementation. By getting these results we can know the difference in the throughput with the variants of TCP and get the comparison of reno and sack.
Keywords: TCP variants, Emulator, NIST Net
[...] However, under Reno, it will not fall back to Slow Start; but instead, it should take advantage of the fact that the flow that currently exists should keep on sending, but using less resources. This is implemented by first halving the size of its cwnd and storing this value in ssthresh. We then set cwnd to ssthresh plus 3*MSS (where 3 is the number of dupacks required to trigger fast retransmit). This will include only up to half of the number of segments just before the Fast Recovery. [...]
[...] Emulation, as defined here, is a combination of two common techniques for testing network code: simulation, which we can define as a synthetic environment for running representations of code; and live testing, a real environment for running real code. In these terms, emulation is a “semisynthetic” environment for running real code. The environment is semi-synthetic in the sense that it is a real network implementation (in the case of NIST Net, the Linux 2.xx kernel) with a supplementary means for introducing synthetic delays and faults. [...]
[...] Two solutions are available: SACK and New Reno TCP SELECTIVE ACFKNOWLEDGEMENT (SACK) Used by the TCP data receiver to acknowledge non-contiguous blocks of data not covered by the Cumulative Acknowledgement field. Use of the SACK option when acknowledging the receipt of a duplicate packet We use the term D-SACK (for duplicateSACK) to refer to a SACK block that reports a duplicate segment. the first SACK block . MUST specify the contiguous block of data containing the segment which triggered this ACK, unless that segment advanced the" Acknowledgment Number field in the header." A SACK option that specifies n blocks will have a length of 8*n+2 bytes, option. [...]
[...] This allows the sender to resend all missing segments without waiting for a timeout RESULTS READINGS FOR TCP SACK Table Drop Rate = Size\Delay Delay Delay Delay 0ms 50ms 100ms 1MB 7.5 e + 03 1e + sec 1.1 sec 8.9 e + sec 9.6 e + sec Delay 250ms 2MB 5MB 5.1 e + 2e + sec 2.1 sec 1.1 e + e + 1.5 e + sec sec 3.9 sec 9.6 e + e + 2e + sec sec sec Table 2 : Drop Rate = Size\Delay Delay Delay Delay Delay 0ms 50ms 100ms 250ms 1MB 7.7 e + 03 1e + sec 1.1 sec 1e + sec 1e + sec 2MB 5MB 5.1 e + 2.1 e + sec 2.1 sec 1.1 e + e + 1.8 e + sec sec 4.3 sec 8.4 e + e + 2.4 e + sec sec 10 sec Size\Delay Delay 0ms 1MB 5e + sec 2MB 5MB Delay Delay Delay 50ms 100ms 250ms 1e + e + 02 2e + sec 2.1 sec 5.3 sec 9.3 e + e + e + e + sec 1.9 sec 4.6 sec 19 sec 3.9 e + e + e + e + sec 7.5 sec 15 sec 42 sec Table 3 : Drop Rate = Size\Delay Delay Delay Delay 0ms 50ms 100ms 1MB 7.8 e + 03 1e + sec 0.14 sec 9e + sec 1e + sec Delay 250ms 2MB 5MB 5.1 e + 2.1 e + sec 2.1 sec 1.1 e + e + 1.8 e + sec sec 3.9 sec 9.7 e + 02 5e + 02 2e + sec 10 sec 25 sec Table 7 : Drop Rate = Size\Delay Delay Delay Delay Delay 0ms 50ms 100ms 250ms 1MB 8e + e + e + 2e + sec 1.7 sec sec 3.4 sec 2MB 8.7 e + e + e + 1.2 e + sec 3.7 sec sec 8.6 sec 5MB 4.2 e + e + e + 1.3 e + sec 7.5 sec sec 13 sec Table 7 : Drop Rate = Size\Delay Delay Delay Delay Delay 0ms 50ms 100ms 250ms 1MB 8.5 e + 03 1e + e + 1.3 e + sec 1.3 sec sec 3.1 sec 2MB 8.8 e + e + e + 8e + sec 2.4 sec sec 9.7 sec 5MB 7e + e + e + 1.1 e + sec 7.9 sec sec sec Table 4 : Drop Rate = Size\Delay Delay Delay Delay 0ms 50ms 100ms 1MB 5.5 e + e + e + 0.19 sec 1.3 sec sec 2MB 9e + e + 3.4 e + 0.23 sec sec 6.1 sec 5MB 1e + e + e + 0.51 sec 5.9 sec sec READINGS FOR TCP RENO Table 5 : Drop Rate = Size\Delay Delay Delay Delay 0ms 50ms 100ms 1MB 8.1 e + 03 1e + sec 1.1 sec Delay 250ms 1.5 e + sec 1.3 e + sec 1.5 e + sec Delay 250ms 2MB 5MB 3.1 e + 2e + sec 3.5 sec 3.8 e + e + e + 1.5 e + sec 3.3 sec sec 3.9 sec 2.9 e + e + e + 1.4 e + sec 8.7 sec sec 15 sec Table 6 : Drop Rate = Fig Throughput graph CONCLUSION After viewing these readings we get the idea about the change in the drop rates of when protocol is modified and this at the end prove that TCP SACK is much better than TCP Reno. [...]
[...] This will cause the tcp connection to slow start up to ssthresh and then congavoid - as with the normal Tahoe implementation MOTIVATION FOR IMPROVING RENO In the Internet, packets are often transmitted in bursts (bursty nature of tcp etc) As a result, losses also often happen in bursts. This is primarily due to FIFO (drop tail) queues in routers. The fundamental problem is that Fast Retransmit assumes that only one segment was lost. This can result in loss of ack clocking and timeouts if more than one segment is lost. [...]
APA Style reference
For your bibliographyOnline reading
with our online readerContent validated
by our reading committee
