Flow Control in TCP 3

---

Flow Control in TCP

---

• Send and Receive buffers
  • When a user application sends data to another user application, the data is first stored in a send buffer inside Operating System kernel:

    ---

  • When the send buffer contains more than MSS bytes or when the send time expires, the TCP module will send the data in a TCP segment to the receiver:

    The receive data is stored in a receive buffer inside the Operating System kernel of the receiver computer

    ---

  • The receiving application can use the read() system call to empty the received data from the receive buffer:

  ---

  ---

• Flow Control
  • Flow control is a mechanism to ensure that the transmissionrate of the sender do not exceed the capacityof the receiver.

  • Fact:

    • If the transmission rate exceeds the capacity of the receiver,then sooner or later,there is no buffer space left to store arriving packets When this happens, newly arriving packetsare discarded

    ---

  • Here's an analogy of what happens when the receiver processing rate is lower than the transmission rate:

    The bucket has a hole that let water drain at 1 Gal / min

    A pipe fills the bucket with water at 2 Gal /min

    Sooner or later, the bucket will overflow

  ---

  ---

• How is flow control implemented ?

  • Flow control in TCP is implemented with theAdvertised Windowsize in the TCP header:

    (Discussion on the TCP header: click here )

    ---

  • Using the Advertised Window Size:

    • The Adv. Win. size is the maximum number of bytes that the receiver is willing to buffer The sender should honor the receiver's request and refrain from sending more data than the given adv. win. size

    Example:

    Notes:

    • The client tells the server not to send more than 300 bytes The server tells the client not to send more than 900 bytes

  ---

  ---

• Receive buffer and Advertised Window Size

  • Factors that determine the Advertised Window Size:

    • The size of the receive buffer that the TCP connection has reserved The receive buffer size is fixed at connection establishment The amount of data currently buffered in the receive buffer

    ---

  • The receive buffer:

    • The receive buffer is located inside the Operating System (kernel). The receive buffer is filled when a data segment is received The receive buffer is emptied (a little bit) when data is read bythe user process The user program can set the maximum receive buffer size by using the setsockopt() system call From the setsockopt man page: The SO_SNDBUF and SO_RCVBUF options adjust the normal buffer sizes allocated for output and input buffers, respectively. The buffer size may be increased for high-volume connections or may be decreased to limit the possible backlog of incom- ing data. The maximum buffer size for UDP is determined by the value of the ndd variable udp_max_buf. The maximum buffer size for TCP is determined the value of the ndd vari- able tcp_max_buf. (Use setsockopt before you create a socket :-)) The default receive buffer size in Solaris is 1 Mbytes cheung@shangchun(2012)> ndd /dev/tcp tcp_max_buf 1048576

  ---

  ---

• Computing the Advertised WindowSize
  • The following types of data can be store in the receive buffer:

    • Deliverable data: Data that has been acknowledges I.e., all preceeding data have been received The application can readily read the data (because the data can be delivered in the order that was transmitted) Undeliverable data: Data that was received, but not been acknowledged because some preceeding data has not been received The application cannot read the data because the data would be read out of the order that was transmitted)

    ---

  • Computing the Advertised Window Size:

  • Clearly, the Advertised WindowSize should be set to:

    • Advertised Window = SizeRecvBuffer - (LastByteRecv - LastByteRead)

  ---

  ---

  ---

  ---

• Flow control in action
  • The effect of flow control is only evident when aspeedier sendertransmits to aslower receiver !!!

  • The following example of flow control uses a receive buffer size of 100 K bytes.

    ---

    ---

    Flow control Example:

    • Initially, the send and receive buffer are empty. Receiver advertises a window of 100 K bytes. Sender sends many packets quickly, faster than the receiver canprocess... the receive buffer starts to fill and soon the advertisedwindow drops to 50 K bytes: The situation continues and the receive buffer fills further The ACK packets from the receiver will now have a lowerthe advertised window, e.g., 1 K bytes: Sooner or later, the receive buffer fills up The receiver returns an ACK packets withthe advertised window = 0 bytes !!! This causes the sending TCP to stop transmitting more data..... and prevented the sending TCP to overflow the receive buffer ofthe receiving TCP. NOTE: This will not stop the sending application from sending more data.... The sending application process can still send more data... but the data sent will remains in the send buffer !!! (as given inthe above figure) If the sending application process continues sending, the send buffer willfill up A subsequent write() call will causethe sending application process to block: Now the faster sending applicationprocess has been successfully throttle...

  ---

  ---

• An advanced programming note
  • The default bahavior of write() is blocking

    • When the send buffer fills up, the write() operation will cause the application to block (wait)

    ---

  • Non-blocking write() operations:

    • The following UNIX system call will change the behavior of write() to non-blocking: fcntl(socket, F_SETFL, fcntl(recvfd, F_GETFL)|O_NDELAY); The write() operation will return −1 when the send buffer is full (otherwise, it will return the number of bytes written)

  ---

  ---

  ---

  ---

• The Block TCP flow problem...
  • Important fact:

    • A receiving TCP protocol modulewill only send an (ACK) packetif it has received a TCP segment.... Rephrased: A receiving TCP protocol modulewill not send an (ACK) packetif it has not receive any TCP segment.... The rephrased statement is pretty obvious --- why would you acknowledge nothing :-)

    ---

  • Unforeseen consequence of Flow Control:

    • Since the advertised window size = 0 at the sender, the sender cannnot send any packet... Consequently, the the receiver may not send any packet to the sender Consequently, the Adverised Window Size of the sender will remain ZERO

    We have a "dead-lock" situation:

    ---

    ---

  • If the advertised window size = 0 at the sender and the sender has some data in the send buffer,the sender will periodically send a one byte TCP segmentto the receiver to trigger a response from the receiver:

    The acknowledgement for the byte size probe TCP segment will contain the new (non-zero) value of the advertised window size that the sender can use to pace its transmissions

---

---

---

---