Transmission Control Protocol (TCP) TCP Flow Control and Congestion Control CS 60008: Internet Architecture and Protocols Department of CSE, IIT Kharagpur Course Instructor: Sandip Chakraborty

TCP Concepts Stream data transfer – From application’s viewpoint, TCP transfers a contiguous stream of bytes – The application does not need to bother about creating data packets/datagrams Reliability – TCP sequence numbers – positive ACK from receiving TCP layer – Data is transmitted in blocks (called a TCP segments), the sequence number of the first data byte is sent as the sequence number of a TCP segment.

TCP Concepts Flow Control – The receiving TCP layer also informs the number of bytes it can receive without causing overflow in its internal buffer Multiplexing – Use of port numbers Logical connections – Reliability and flow control require that the sending and receiving TCP ends synchronize with some initial parameters, like the sequence number and window sizes Full Duplex

The Window Principle The sender can send all packets within the window without receiving an ACK, but must start a timeout timer for each of them. The receiver must acknowledge each packet received, indicating the sequence number of last well-received packets. The sender slides the window with each ACK received.

The Window Principle Let Packet 2 get lost! – The sender will not receive ACK 2, so it will remain at position 1 – Since the receiver did not received packet 2, it will acknowledge packet 3, 4 and 5 with and ACK 1 – Eventually a timeout will occur for packet 2, and it will be retransmitted – As the receiver has received packet 2, 3, 4 and 5 now, it will send and ACK 5, and the sender window will slide.

The Window Principle Let ACK 2 get lost! – The sender will not receive ACK 2, but it will receive ACK 3 – ACK 3 indicates that it has received all packets up to packet 3

The Window Principle The window mechanism ensures – Reliable transmission – Better use of network bandwidth (better than stop and wait) – Flow control The receiver can delay replying to a packet with an acknowledgement, if its buffer is full

Window Mechanism Applied to TCP TCP provides byte-stream connection – sequence numbers are assigned to each byte in the stream TCP divides this contiguous byte streams into TCP segments The window principle is applied at the byte level – The sequence sent and acknowledgement received will carry byte sequence numbers and the window size is expressed as the number of bytes.

Window Mechanism Applied to TCP

TCP Segment Format

TCP Acknowledgement and Retransmission Process Segment Size: 500 bytes Window Size: 1500 bytes

TCP Congestion Control Algorithms Slow Start Congestion Avoidance Fast Retransmit Fast Recovery

Slow Start Prime Observation: The rate at which new packets should be injected into the network is the rate at which the acknowledgements are returned by the other end. Slow start adds another window to the sender’s TCP : the congestion window (cwnd). Whenever a new connection is established with a host at another network, cwnd is initialized to one segment Each time an ACK is received, cwnd is increased by one segment

Slow Start The sender transmits at the lower value of congestion window and the advertised window (advertised by the receiver during the connection establishment) Congestion window: Flow control imposed by the sender – based on sender’s assessment of perceived network congestion Advertised window: Flow control imposed by the receiver – based on amount of available buffer space at the receiver

Slow Start Provides an exponential growth, although it is not exactly exponential. Receiver might delay its ACK for flow control.

Slow Start At some point, the capacity of the IP network is reached ! An intermediate router starts discarding the packets… This tells the sender that its congestion window has gotten too large – need congestion avoidance !!!

Congestion Avoidance Assumption: Packet loss due to channel error is very less (less than 1%) – therefore, loss of a packet signals congestion somewhere between the source and destination. There are two indications of packet loss, – A timeout occurs – Duplicate ACKs are received Congestion avoidance and slow start are independent algorithms with different objectives, – Slow start: Find out the available capacity between the source and destination – Congestion avoidance: Reduce the flow rate if congestion occurs However, in practice, they are implemented together because after reducing the flow rate on detection of congestion, available capacity of the link need to be calculated again.

Slow Start + Congestion Avoidance Congestion avoidance and slow start maintains two variables; – A Congestion window (cwnd) – A slow start threshold size (ssthresh)

Slow Start + Congestion Avoidance The combined algorithm operates as follows: – For a given connection, initialize cwnd to 1 segment and ssthresh to bytes – The TCP output routine sends at a rate of min(cwnd, advwnd) where advwnd is the receiver’s advertised window – When congestion occurs (timeout of duplicate ACK), one-half of the current window size is saved in ssthresh. Additionally, if the congestion is indicated by a timeout, cwnd is set to one window. – When new data is acknowledged by the other end, increase cwnd, as follows: If cwnd is less than or equal to ssthresh, TCP is in slow start (exponential growth) If cwnd is more than ssthresh, TCP is in congestion avoidance (linear growth)

Congestion Avoidance Cwnd is incremented by segsize*segsize/cwnd, each time an ACK is received – segsize is segment size in bytes. The increase in cwnd is at most one segment per round trip time (regardless of how many ACKs are received in a round trip time) – Linear increase

Congestion Avoidance

Fast Retransmit Fast retransmits avoids having TCP wait for a timeout to resend lost segments. TCP can generate an immediate ACK (a duplicate ACK) when an out-of-order segment is received. This duplicate ACK should not be delayed – the purpose is to let the other end know that a segment was received out of order and to tell what sequence number is expected. TCP does not know whether a duplicate ACK is caused by a lost segment or just a reordering of segments – it waits for a small number of duplicate ACKs to be received.

Fast Retransmit Assumption: If there is just a reordering of segments, there will be only one or two duplicate ACKs, before the reordered segment is processed. If three or more duplicate ACKs are received in a row, it is a strong indication that a segment has been lost. TCP then performs a retransmission of what appears to be missing segment, without waiting for a retransmission timer to expire.

Fast Retransmit

Fast Recovery Fast retransmit sends what appears to be the missing segments. What should TCP do next? – Congestion Avoidance – Slow Start

Fast Recovery Receipt of duplicate ACKs tells TCP more than just a packet has been lost. The receiver can only generate duplicate ACKs when another segment is received -> that segment has left the network and is in the receiver buffer -> indicates there is still data flowing between the two ends. TCP does not want to reduce the flow abruptly by going into slow start -> start congestion avoidance instead of slow start

Fast Retransmit + Fast Recovery When the third duplicate ACK in a row is received, set ssthresh to one-half of the current cwnd, but no less than two segments. Retransmit the missing segment. Set cwnd to ssthresh plus three times the segment size – This inflates the cwnd by the number of segments (3) that have left the network and the other end has cached.

Fast Retransmit + Fast Recovery Each time another duplicate ACK arrives, increment cwnd by one segment size. – This inflates the cwnd for the additional segment that has left the network – Transmit a packet, if allowed by the new value of the cwnd. When the new ACK arrives that acknowledges the new data, set cwnd to ssthresh. – This ACK is the acknowledgement of the retransmission. – Additionally, it acknowledges all the intermediate segments sent between the lost packet and the receipt of the first duplicate ACK.

Fast Retransmit + Fast Recovery

TCP Tahoe vs TCP Reno