Presentation on theme: "Transport Layer – TCP (Part2) Dr. Sanjay P. Ahuja, Ph.D. Fidelity National Financial Distinguished Professor of CIS School of Computing, UNF."— Presentation transcript:
Transport Layer – TCP (Part2) Dr. Sanjay P. Ahuja, Ph.D. Fidelity National Financial Distinguished Professor of CIS School of Computing, UNF
Opening a TCP Connection with the Three-Way Handshake When the SYN segment (client sends this segment by a CONNECT socket call) arrives at the destination, the TCP entity at the server checks to see if there is a process that has done a LISTEN on the port # specified. If not, it sends a reply with the RST bit set to 1 to reject the connection. Server responds with SYN+ACK segment (sent by the ACCEPT socket call). The final handshake is an ACK to inform the server that both sides agree that a connection has been established. The three-way handshake guarantees that both sides are ready to transfer data and they know both are ready. It also allows both sides to agree on initial sequence numbers which are randomly chosen. Random selection of initial sequence numbers is to ensure against two incarnations of the same connection reusing the same sequence numbers too soon.
Closing a TCP Connection Closing a TCP connection is symmetric, i.e. both sides must close the connection. An application program that has no more data to send invokes the CLOSE socket call to send a FIN segment to close its end of the connection. TCP then closes the connection in one direction. More data can continue to flow in the opposite direction until the other side also closes the connection. If a response to FIN segment is not received in two max packet lifetimes (2 * 120 seconds), the sender of the FIN segment releases the connection. The other side will notice that nobody is listening and it will timeout as well.
TCP Transmission Policy using Sliding Window
TCP Congestion Control with Jacobson’s Slow Start Algorithm When load offered to any network is more than it can handle, congestion builds up. The solution is to slow down the data rate and so TCP handles congestion control. Detecting Congestion Most transmission timeouts on the Internet are due to congestion (since packets are likely to be discarded at congested routers or ACKs may be delayed) and so the TCP congestion control algorithm assumes that timeouts are caused by congestion and watch out for timeouts. There are two potential problems: Network Capacity and Receiver Capacity and the TCP deals with each of them separately. Each sender maintains two windows: the window granted by the receiver and the congestion window. The number of bytes sent is the minimum of the two windows.
TCP Congestion Control with Jacobson’s Slow Start Algorithm When a connection is setup, the sender initializes: congestion window = size of 1 MSS It then sends 1 segment. If this segment is ACKed before the timer goes off, it adds one segment worth of bytes to the congestion window (now 2 MSS) and then sends 2 segments. As each of these two segments are ACKed, the congestion window is increased by 1 MSS. So when both these segments are ACKed, the congestion window would now be equal to 4 MSS. When congestion window = n segments and all n are ACKed on time, congestion window = 2 * n. In effect, each burst of segments successfully ACKed doubles the congestion window. The congestion window grows exponentially until either a timeout occurs or the receiver’s window is reached. This algorithm called Slow Start was proposed by Jacobson.
TCP Congestion Control with Jacobson’s Slow Start Algorithm This congestion control algorithm also has a third parameter, the threshold, which is initialized to 64 KB. When timeout occurs: threshold is set to half of the current congestion window, congestion window is reset to 1 MSS. Slow Start is then used to determine what the network can handle except that exponential growth stops when the threshold limit is hit. From that point on, successful transmissions grow the congestion window linearly (by 1 MSS per burst instead of 1 MSS per segment). If no more timeouts occur, congestion window will continue to grow up to the size of the receiver’s window (this ensures flow control. i.e., the receiver’s buffer will not overflow). Then congestion control stops growing and remains constant as long as no more timeouts occur and receiver’s window does not change in size.
TCP Congestion Control with Jacobson’s Slow Start Algorithm