Internet is expanding rapidly over entire glob with heterogeneous networks. TCP/IP protocol suite is an
inseparable part of Internet. Hence, the efficiency of the protocols is plays a vital role in performance of Internet. The increasing use of wireless links in expanding Internet has brought out some serious performance issues of TCP, which was originally designed and deployed over a wired network. Wired links are less prone to channel errors. Due to inherent problem of TCP, it fails to differentiate losses by actual reason, so they are not treated fairly. Therefore, performance is often compromised by unnecessary congestion window, cwnd reductions and RTOs. Basic TCP has gone through a number of revisions in order to improve performance. Among all of them, SACK TCP is considered to be the most efficient scheme because of its ability to avoid unnecessary retransmissions based on SACK information. SACK TCP also fails to discriminate the cause of the loss: congestion or corruption. If random losses can be categorized apart from losses due to severe congestion, then irrational decision of 'cwnd' reduction can be avoided. This will surely lead to performance improvement due to effective bandwidth utilization and consistent flow in random packet losses. In this paper, SACK TCP is modified to delay fast recovery after one packet loss, until subsequent loss in the same windows is encountered.
Keywords: TCP SACK, cwnd, Congestion, Corruption, Fast Recovery
[...] TCP Reno's Fast Recovery algorithm is optimized for the case when a single packet is dropped during a window of data. The TCP Reno retransmits at most one dropped packet per round-trip time. TCP Reno significantly improves upon the behavior of TCP Tahoe when a single packet is dropped from a window of data, but can suffer from performance problems when multiple packets are dropped during a window of data TCP New-Reno TCP New-Reno is the enhanced TCP Reno using a modified version of Fast Recovery Janey Hoe proposed a modification to TCP Reno usually called New-Reno, which addressed two problems in TCP Reno, these ideas are gradually finding acceptance within the IETF. [...]
[...] SIMULATION TOPOLOGY Erroneous Environment with no Congestion Fig Simulation Topology 1 Congested Network with an Erroneous Link Table Number of Packets Delivered (Errors & Congestion 100 Seconds) Error Rate Original SACK Modified TCP SACK TCP CONCLUSIONS Fig Simulation Topology 2 Simulations were carried out on ns-2 with two types of topologies: erroneous but congestion free environment & congested network along with random errors. Following observations were made from the results of simulations attempted on baseline and modified SACK TCP schemes. [...]
[...] Availability of the SACK information allows the TCP sender to make congestion control more accurately. When three duplicate ACKs are arrived by SACK TCP, the sender cuts the cwnd uniformly by half and an estimating outstanding data variable pipe, to control the number of segment sent during fast recovery phase. Considering three duplicate acknowledgements to implicitly indicate that receiver receives three outstanding packets, the pipe size is estimated to (cwnd and then cwnd is halved. The variable pipe is increased by one segment when sending a packet and decreased by one segment when receiving a duplicate acknowledgement or decreased by two when received a partial acknowledgement. [...]
[...] based comparison of modified SACK TCP and original SACK TCP shows significant improvement in case of random errors. There is no degradation in a network facing severe congestion. Results are demonstrated at the end with help of graphs of throughputs and percentage improvement in terms of packet delivered. Keywords: TCP SACK, cwnd, Congestion, Corruption, Fast Recovery TCP The Transport Control Protocol, TCP, is a protocol that runs on the top of the IP network layer. In TCP, the receiver acknowledges all received data with an ACK message, and the sender buffers the sent data until an ACK packet is received. [...]
[...] At sender side, SACK blocks report number of packets successfully reaching the receiver out of order after a loss. Sender can u7se this information effective to be sure about a random loss. After reception of a dupack, sender can check right edge of the SACK block. As long as the loss is the only one, continuous increment in right edge is reported to sender. Whenever another loss is detected, right edge discontinuous to increment as expected at sender side and a gap will be noticed. [...]
using our reader.