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

Flow Control in TCP

---

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

    ---

  • When the send buffer containsmore than MSS bytes or when thesend timeexpires, 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 thereceived data from the receive buffer:
    

  ---

  ---

• Flow Control
  • Flow control is a mechanism to ensure that thetransmissionrate of thesender do not exceed thecapacityof 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 thetransmission rate:
    

    The bucket has a hole that letwater drain at1 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 sendingmore 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 thereceive 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 is1 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 hasnot been received

      The application cannot read the data because the datawould be readout 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:

    1. Initially, the send and receive buffer are empty.

       Receiver advertises a window of 100 K bytes.

       

       ---

    2. 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:

       

       ---

    3. 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:

       

       ---

    4. 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)

       ---

       ---

    5. If the sending application process continues sending, thesend buffer willfill up

       A subsequent write() call will causethesending application process toblock:

       

       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 toblock (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 thesend buffer is full (otherwise, it will returnthe 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 hasnot receive any TCP segment....

      The rephrased statement is pretty obvious --- why would youacknowledgenothing :-)

    ---

  • Unforeseen consequence of Flow Control:
    • Since the advertised window size = 0 at thesender, thesender 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 senderhas some data in thesend buffer,the sender willperiodically send aone byte TCP segmentto the receiver totrigger a response from thereceiver:
    

    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 topace its transmissions

---