Abstract

Transport Control Protocol (TCP) incast congestion happens when a number of senders work in parallel with the same server where the high bandwidth and low latency network problem occurs. For many data center network applications such as a search engine, heavy traffic is present on such a server. Incast congestion degrades the entire performance as packets are lost at a server side due to buffer overflow, and as a result, the response time becomes longer. In this work, we focus on TCP throughput, round-trip time (RTT), receive window and retransmission. Our method is based on the proactive adjust of the TCP receive window before the packet loss occurs. We aim to avoid the wastage of the bandwidth by adjusting its size as per the number of packets. To avoid the packet loss, the ICTCP algorithm has been implemented in the data center network (ToR).

Highlights

  • In this work, our discussion is mainly focused on the congestion problem that usually occurs in incast, a condition which is the opposite of broadcast

  • The receiver side is a natural choice since it knows the throughput of all Transport Control Protocol (TCP) connections and the available bandwidth

  • We suggest calling this design Incast congestion Control for TCP (ICCTCP)

Read more

Summary

Introduction

Our discussion is mainly focused on the congestion problem that usually occurs in incast, a condition which is the opposite of broadcast. The congestion happens when many synchronized servers work under the same switch and TCP is not very reliable for high-bandwidth and low latency networks. The receiver side can adjust the receive window size of each TCP connection so that the aggregate bursts of all the synchronized senders are kept under control. We suggest calling this design Incast congestion Control for TCP (ICCTCP). The technical novelties of this work are as follows: 1) To perform congestion control on the receiver side, we use the available bandwidth on the network interface as a quota to coordinate the receiver window increases of all incoming connections

Objectives
Results
Conclusion
Full Text
Paper version not known

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.