RSA TCP can improve the performance which is usually encumbered by the congestion or connection down on the link of an access host side. If the TCP server contains multiple solid interfaces to access the network in the same time, the reliability can be strengthened by RSA TCP. If RSA TCP detects the condition happened on the path, RSA TCP switches the transmission to a next path. The effort on switching is not much. RSA TCP provides a smooth switching among the paths. Effects to the users might be too small to know. For TCP servers, especially Video on Demand systems, RSA TCP is very helpful to raise the reliabilities, bandwidth utilization and seamless switching
For a homogeneous network, the inter-nodes between source and destination will be past through in a few hops. Only if the congestion occurs at the near end of the TCP sender, the path switching is still useful. In generic cases, congestion occurs at many nodes. If there are packets lost, the packets might be dropped in many nodes because of the traffic loading or destination being unreachable. So, RSA TCP might help users to switch to a solution in homogeneous network. It might be not, either.
The modifications to the packets which are switched to a new path by RSA TCP are only the next hop address. Due to the change of the header, the checksum needs to re-calculate, too.
For advanced identification, it is possible for RSA TCP to new add a field or option to carry the switching information, including the specific identification number and the IP information of original main trunk. After receiver got the packets, receiver can subtract the IP information
(14)
64
from the option field. The identification to the packet is more comprehensive.
For heterogeneous network, there are very few inter-nodes for common. Maybe only the routers located in front of the destination. The TCP sender has two or more interfaces to connect to different media of network. For example, when TCP sender detects that the Ethernet is congested, TCP sender can deliver the packets to another interface, such as 3G network. The 3G network is private and maintained by the Telephone Communication companies. The network has very high bandwidth and the network is also very stable. If the sender gives up the congestion path and transfers to a stable one, the performance will be improved very much. Conclusively speaking, RSA TCP can help to get out of the congested path. If there is a clean path backup, RSA TCP is able to automatically eliminate the failure situation and maintain the good throughput. If there is no paths backup or all other paths are busy too, RSA TCP can help nothing. No matter what path RSA TCP selected, any one of them is heavy loaded. At this time, the selection is meaningless.
RSA TCP picks up the available path as new path not picks up good path as new path. In the future, RSA TCP should clone some packets to deliver to different networks, including the congested one and next one. RSA TCP has to try detecting the status of the new path.
Switching data path to a congested one is meaningless. If RSA TCP can always pick up a clean path to be a backup of congested paths, the TCP performance will be improved entirely.
So RSA TCP needs a mechanism to find out the traffic loading among paths. Furthermore, the routing information in the network might be changing all the time. RSA TCP also needs source routing abilities. Source routing can direct the data packets to travel on the nodes with loose traffic. Surely, the source routing with intelligence also helps to do the loading balance.
RSA TCP prepares some space to store the results of the status in the network. The value should be referred before collecting the paths. The periodical polling collects the information of status in the network and maintains the status table. As the data path switching is required
(13)
65
to go, the table can provide the most precise information to reference. If this can be done, the RSA TCP can improve the performance both in heterogeneous network and in homogeneous network, especially the Internet.
66
Reference
[1] J. Postel, Transmisson Control Protocol, IETF RFC793, Sep. 1981.
[2] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM '88, pp.273-288, 1988.
[3] V. Jacobson, Modified TP Congestion Avoidance Algorithm, mailing list, end2end-interest, 1990 Apr. 30. ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt [4] W. Stevens, TCP Slow Start,Congestion Avoidance, Fast Retransmit, and
Fast Recovery Algorithms, RFC 2001, Jan. 1997.
[5] M. Allman, V. Paxson, and W. Stevens., TCP Congestion Control, RFC 2581, Apr. 1999.
[6] S. Floyd, T. Henderson, The NewReno Modification to TCP's Fast Recovery Algorithm, RFC 2582, Internet Request for Comments 2582, Apr. 1999.
[7] C. Baraket, E. Altman, and W. Dabbous, On TCP Performance in a Heterogeneous Network, IEEE Communications Magazine, Vol. 38, no. 1, pp. 44-46, Jan. 2000.
[8] M. Mathis, et al., TCP Selective Acknowledgement Options", IETF RFC 2018, 1996.
[9] J. S. Ahn, et al, Evaluation of TCP Vegas: Emulation and Experiment, Proc. of ACM SIGCOMM, pp. 185-195, Aug. 1995.
[10] L. S. Brakmo, S. W. O'Malley, and Larry L. Peterson, TCP Vegas: New Techniques for Congestion Detection and Avoidance, Proc. of ACM SIGCOMM, pp. 24-35, Aug. 1994.
[11] L. S. Brakmo, Larry L. Peterson, TCP Vegas: End to End Congestion Avoidance on a Global Internet, IEEE Journal on Selected Areas in Communication, vol. 13, no.8, pp. 1465-1480, Oct. 1995.
[12] Peter Dimopoulos, et al, Multipath Aware TCP (MATCP), Processing of the 11th IEEE Symposium on Computers and Communications
(ISCC'06), 2006 IEEE
[13] Thinh Nguyen, Sen-ching S. Cheung, Multimedia Streaming Using Multiple TCP Connections.
[14] Jia-Ching Shiu, FTCP, Csnoop - Two Novel Strategies for TCP over Wired and Wireless Network, 2003
[15] Wei-Kuang Lai, Buffer Management with Consideration of States in TCP
67
Connections, 2001
[16] Tsuh-Feng, Chu, A Dynamic Queue Adjustment Based on Packet Loss Ratio in Wireless Networks, 2003
[17] Dilip Sarkar, A Concurrent Multipath TCP and Its Markov Model, IEEE ICC 2006 proceedings.
[18] http://www.isi.edu.tw/nsnam.ns/.
[19] Yohei Hasegawa, et al, Improved Data Distribution for Multipath TCP Communication", IEEE Globecom 2006.
[20] Vinh Bui and Weiping Zhu, Improving multipath live streaming performance with Markov Decision Processes ", 2007 International Symposium on Communications and Information Technologies (ISCIT 2007).