Flow Control in TCP（tcp的流量控制实现)

Flow Control in TCP

---

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

    ---

  • When the send buffer containsmore than MSS bytes or when thesend time expires, the TCP module will send the data in aTCP segment to the receiver:

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

    ---

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

  ---

  ---

• Flow Control
  • Flow control is a mechanism to ensure that thetransmissionrate 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 storearriving packets When this happens, newly arriving packetsarediscarded

    ---

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

    The bucket has a hole that letwater 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 theTCP 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 andrefrain from sending more data than the givenadv. 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 currentlybuffered in the receive buffer

    ---

  • The receive buffer:

    • The receive buffer is locatedinside 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 themaximum receive buffer size by using thesetsockopt() 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 inSolaris 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 thereceive buffer:

    • Deliverable data: Data that has been acknowledges I.e., all preceeding data have beenreceived The application can readily read the data (because the data can be delivered in theorder that was transmitted) Undeliverable data: Data that was received, but not been acknowledged because somepreceeding data has not been received The application cannot read the data because the datawould 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 isonly evident when aspeedier sendertransmits to aslower receiver !!!

  • The following example of flow control uses areceive 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, thesend buffer willfill up A subsequent write() call will causethesending application process to block: Now the faster sending applicationprocess has beensuccessfully throttle...

  ---

  ---

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

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

    ---

  • Non-blocking write() operations:

    • The following UNIX system call will change the behavior of write() tonon-blocking: fcntl(socket, F_SETFL, fcntl(recvfd, F_GETFL)|O_NDELAY); The write() operation willreturn −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 modulewillonly send an (ACK) packetif it has received a TCP segment.... Rephrased: A receiving TCP protocol modulewillnot send an (ACK) packetif it has not receive any TCP segment.... The rephrased statement is pretty obvious --- why would youacknowledge nothing :-)

    ---

  • Unforeseen consequence of Flow Control:

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

    We have a "dead-lock" situation:

    ---

    ---

  • If the advertised window size = 0 at thesender and the sender has some data in thesend buffer,the sender will periodically send aone 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 thesender can use to pace its transmissions

---