{"id":191,"date":"2020-11-28T14:57:51","date_gmt":"2020-11-28T19:57:51","guid":{"rendered":"https:\/\/www.alpharithms.com\/?p=191"},"modified":"2021-07-20T22:45:10","modified_gmt":"2021-07-21T02:45:10","slug":"tcp-flow-control","status":"publish","type":"post","link":"https:\/\/www.alpharithms.com\/tcp-flow-control-515714\/","title":{"rendered":"TCP Flow Control: A Robust Speed Matching Service"},"content":{"rendered":"

TCP Flow Control uses a system of buffers and variables to determine how quickly data can be transmitted. The underlying concept is that a receiving end system is able to notify the sending end system that its application is unable to keep up with the transmission rate.<\/p>\n

Flow Control is\u00a0not<\/em> the same as TCP’s congestion control system<\/a>\u2014a system for detecting\u00a0network<\/em> issues. Rather, TCP’s flow control system is designed to detect end-system issues.<\/p>\n

All About Buffers<\/h2>\n

Transmission Control Protocol (TCP)<\/a> involves a series of buffers for both senders and receivers. These buffers serve as intermediaries between the transport layer and the application layer. TCPs flow control mechanisms leverage the dynamics of these buffers to create a speed matching service<\/strong> to prevent packet overflow.<\/p>\n

When an application layer\u00a0sends<\/em> data packets via TCP, these data are placed in a send buffer. When an application\u00a0receives<\/em> data, those bits are placed into a buffer prior to being read.<\/p>\n

When a sender transmits data faster than a receiver application can consume from its receiving buffer\u2014you get buffer overflow<\/strong> (not to be confused with integer<\/em> overflow<\/a>.) TCP flow control is designed to avoid this and, when experienced, adjust the transmission rate<\/em> on the sender side to compensate.<\/p>\n

Buffer Feedback<\/h3>\n

In the case of receiving data; data placed into the buffer has been deemed valid and in-sequence by TCP’s reliable data transfer (RDT) services. Receiving buffers may receive data faster than applications are able to handle. In such cases, a sender could quickly overflow the receiver’s buffer if a control mechanism were not in place.<\/p>\n

TCP’s flow control service helps prevent this from happening. Conceptually, TCP flow control is a\u00a0speed matching<\/em> service that helps a sender rate-limit data transmission to match the receiver’s capacity to process it’s receiving buffer.<\/p>\n

TCP’s send rate can be throttled by congestion control measures as well but these are separate from flow-control measures and descriptive of network conditions\u2014not end system bandwidth.<\/p>\n

Sliding Windows<\/h2>\n

TCP uses what’s known as a sliding window protocol to determine the total amount of data being transmitted. This measure helps control the number of unacknowledged packets being transmitted. In other words, when to stop sending and wait to make sure things are being received.<\/p>\n

TCP does this by establishing a “window” in which a sequence of packets are “authorized” to be sent. When a sending system receives an acknowledgment (ACK) from the receiving system, the window is incremented to authorize new packets for sending.<\/p>\n

There are several strategies by which the receive window is utilized, including go-back-n<\/strong> and selective repeat<\/strong> but its fundamental function remains the same: determining which packets are being sent. Let’s take a closer look at the receive window.<\/p>\n

Receive Window<\/h2>\n

TCP’s Flow Control is maintained by a variable, on the sender side, called the receive window<\/strong>. This value essentially tracks the amount of space left in the buffer on the receiver side after the existing data is accounted for. The formula for calculating the receive window is rwnd = receiveBuffer - (lastByteReceived - LastByteRead)<\/code>. This is illustrated as such:<\/p>\n

\"tcp
The receive window variable lets the sender track the available buffer space at the receiver<\/figcaption><\/figure>\n

The receiveWindow<\/code> variable is constantly updated and reported to the sending system via the window segment of the TCP header. Keeping the above illustration in mind, there are some important relationships that must be maintained between the receiveBuffer<\/code>, receiveWindow<\/code>, lastByteRead<\/code>, and lastByteReceived<\/code>.<\/p>\n

When the receive buffer is full, the receiver sends a receiveWindow = 0<\/code> notice to the sender. This creates a problem once the receiver’s application has consumed the remaining buffer data; there’s nothing left to send back to the initial sender in terms of AKC’s. This would effectively transition the sender to an indefinite state of waiting\u2014a firm block of data transmission.<\/p>\n

To get around this issue, TCP makes explicit consideration by dictating the sender will continue to send a single bit of data to the receiver. This minimizes strain on the network while also maintaining a constant check on the status of the receiving buffer in a way that would return an ACK as soon as things free up!<\/p>\n

Review<\/h2>\n

TCP offers flow control mechanisms to ensure a receiving application doesn’t collect data faster than it’s able to consume it. This mechanism relies on the window field in the TCP header and provides an effective speed-matching system to help support TCP’s reliable data transport service.<\/p>\n","protected":false},"excerpt":{"rendered":"

TCP Flow Control uses a system of buffers and variables to determine how quickly data can be transmitted. The underlying concept is that a receiving end system is able to notify the sending end system that its application is unable to keep up with the transmission rate. Flow Control is\u00a0not the same as TCP’s congestion […]<\/p>\n","protected":false},"author":2,"featured_media":195,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[3],"tags":[6],"acf":[],"_links":{"self":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/191"}],"collection":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/comments?post=191"}],"version-history":[{"count":2,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/191\/revisions"}],"predecessor-version":[{"id":196,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/191\/revisions\/196"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/media\/195"}],"wp:attachment":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/media?parent=191"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/categories?post=191"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/tags?post=191"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}