No / People, systems, and things in the cities generate large amount of data which is considered to be the most scalable asset of any smart city. Linux users are rapidly increased in last few years, and many large multinational organizations are deploying long distance high bandwidth (LDHB) cloud networks for centralizing the data from various smart cities on a central location. TCP is responsible for reliable communication of data in these cloud networks. For reliability communication among various smart cities, a number of TCP congestion control mechanisms have been developed in the past. TCP Compound, TCP Fusion, and TCP CUBIC are the default TCP congestion control mechanisms for Microsoft Windows, Sun Solaris, and Linux operating systems respectively. The response function of TCP CUBIC is higher than the response function of Standard TCP, which is a trademark congestion control mechanism. As a result, TCP CUBIC does not behave friendly with Standard TCP in LDHB cloud networks. The Congestion Window (cwnd) reduction and growth of TCP CUBIC is very aggressive, which causes high packet loss rate and unfair share of available link bandwidth among competing flows from various smart cities. The aim of this research is to design a new TCP congestion control mechanism for Linux operating system to achieve maximum performance in LDHB cloud networks being used by smart cities. In this paper, congestion control module for slow start (CCM-SS) is designed by increasing the lower boundary limit of cwnd size in slow start phase of communication. Congestion control module for loss event (CCM-LE) is designed by increasing the cwnd reduction rate at each packet loss event and finally Advance Response Function for TCP CUBIC (ARFC) is proposed to design a new congestion control mechanism for Linux operating system. NS-2 is used to compare the performance of TCP CUBIC* with TCP CUBIC in short distance high bandwidth (SDHB) and long distance high bandwidth (LDHB) cloud networks. Results show that TCP CUBIC* has outperformed in LDHB networks, at least by a factor of 18% as compared to TCP CUBIC.

No description available.