Copyright © Lopamudra Roychoudhuri Network Protocols Chapters 13 and 15 (TCP/IP Suite Book): TCP Flow and Error Controls Copyright © Lopamudra Roychoudhuri

Flow Control Flow control regulates the amount of data a source can send before receiving an acknowledgment from the destination. TCP defines a window that is imposed on the buffer of data delivered from the application program. Basic elements: rwnd (receiver window), sequence numbers, acknowledgment numbers, timers.

Flow control: Stop-and-wait protocol (not in TCP) Time Contd. from left Stop-and-wait protocol: At most one outstanding Protocol Data Units (PDUs) Sliding window (used in TCP): allows more than one outstanding PDUs

TCP Sender Sliding window Receiver window Congestion window A sliding window is used to make transmission more efficient to control the flow of data so that the destination does not become overwhelmed with data The sender window is opened, closed, or shrunk

Figure 15.22 Sender window example Open – move the right wall to right Makes more data eligible for sending Close – move the left wall to right Some bytes have been acknowledged by receiver, sender need not worry about those bytes anymore Shrink – move right wall to left – not recommended

Figure 15.23 Receiver window Open – move the right wall to right Makes more data eligible for receiving from sender Close – move the left wall to right Some bytes have been received and acknowledged, waiting to be consumed by application layer process

Example 1 What is the value of the receiver window (rwnd) Receiver B sends to Sender A if B has a buffer size of 5,000 bytes and 1,000 bytes of received, ack’ed data, but not processed by the application yet? Solution The value of rwnd = 5,000 − 1,000 = 4,000. Receiver can receive only 4,000 bytes of data before overflowing its buffer. Receiver advertises this value as rwnd in its next segment to Sender. New Left wall Old Left wall closing 1000 Bytes received and ack’ed, but unprocess -ed by application 4000 Bytes that can be received from sender Receiver window Right wall old rwnd=5000 new rwnd=4000

Example 2 An unrealistic example of a Sender sliding window. In reality the values are in thousands of bytes. We assume that cwnd is 20. The sender has sent bytes up to 202. The receiver has sent an acknowledgment number of 200 with an rwnd of 9 bytes. The size of the sender window is thus the min(cwnd, rwnd), or 9 bytes. Bytes 200 to 202 are sent, but not acknowledged. Bytes 203 to 208 can be sent without worrying about acknowledgment. Bytes 209 and above cannot be sent. Sender window Fig. 1

Fig. 1 repeated Sender Window Example 3 In Figure 1 the Sender now receives a packet with an acknowledgment value of 202 and an rwnd of 9. The Sender has already sent bytes 203, 204, and 205. The value of cwnd is still 20. Show the new window.

Fig. 2 Sender Window Example 4 In Figure 2 the sender receives a packet with an acknowledgment value of 206 and an rwnd of 12. The sender has not sent any new bytes. The value of cwnd is still 20. Show the new window.

Fig. 3 Sender Window Example 5 In Figure 3 the sender receives a packet with an acknowledgment value of 210 and an rwnd of 5. The sender has sent bytes 206, 207, 208, and 209. The value of cwnd is still 20. Show the new window.

Example 5 – Sender Window shrinking Current left wall Current right wall

Example 9 How can the receiver avoid shrinking the window in the previous example? Solution The receiver needs to keep track of the last acknowledgment number and the last rwnd. If we add the acknowledgment number to rwnd we get the byte number following the right wall. If we want to prevent the right wall from moving to the left (shrinking), we must always have the following relationship. new ack + new rwnd ≥ last ack + last rwnd or new rwnd ≥ (last ack + last rwnd) − new ack New ack = 210, new rwnd = 5 Last ack = 206, last rwnd = 12 210+5 is not ≥ 206+12 The receiver needs to wait until more buffer is free before sending ack

Window shutdown Receiver can temporarily shutdown the window by sending rwnd = 0 Sender stops sending data temporarily When rwnd = 0, Sender can keep checking the status of the receiver by sending 1 byte to prevent a deadlock We will see this later in TCP timers

Figure 15.25 An example of flow control and acknowledged, by process, window opens by 100 bytes by 200 bytes

Note: Some points about TCP’s sliding windows: ❏ The size of the window is the minimum of rwnd and cwnd. ❏ The source does not have to send a full window’s worth of data. ❏ The window can be opened or closed by the receiver, but should not be shrunk. ❏ The destination can send an acknowledgment at any time as long as it does not result in a shrinking window. ❏ The receiver can temporarily shut down the window; the sender, however, can always send a segment of one byte after the window is shut down.

Receiver window Rules in a nutshell The receiver left wall moves right (‘closes’) when receiver acks For example, if receiver acks 1001, the left wall moves right to the left of byte# 1001 The receiver right wall moves right (‘opens’) when a number of bytes from the extreme left have been consumed by the application For example, if the receiver application process has consumed 100 bytes from left, the right wall will move right by 100 bytes 1001

Sender window rules in a nutshell The sender left wall moves right (‘closes’) when it gets ack from the receiver For example, when receiver acks 1001, sender left wall moves right to the left of byte# 1001 The sender right wall moves right (‘opens’) as a combination of receiver ack and rwnd (new ack + new rwnd) must be ≥ (last ack + last rwnd) for the right wall to move right Right wall moves right by the amount (new ack + new rwnd) - (last ack + last rwnd) In slide 15, the sender right wall moves by 100 bytes after step 7, because (new ack + new rwnd)(step 7) - (last ack + last rwnd)(step 5) = (601+400) – (301+600) = 100 1001

Silly window syndrome The sending TCP may create a silly window syndrome if it is serving an application program that creates data slowly, for example, 1 byte at a time. Problem with Sliding Window Protocol Sender process may generate data to send very slowly Or receiver process may read data very slowly What is the effect of the above two cases? Results in sending very small segments (at worst case each segment has 1 byte of data) How does this effect efficiency? 40 bytes of overhead for 1 byte of data

Silly Window Syndrome Solution – Slow Sender The sending TCP must be forced to wait and collect data to send in a larger block. Nagle’s Algorithm 1 Sending TCP sends first piece of data it receives from the sending application. 2. After sending 1st segment, sending TCP accumulates data in output buffer until a. It receives an Ack b. Or until sender has enough data to fill a max segment size (MSS) 3. Repeat 2

Silly Window Syndrome Solutions – Slow Receiver Clark’s Solution – window shutdown 1 Receiver sends Ack as soon as data arrives 2. But announces a window size of Zero (0) until there is enough space to accommodate a segment of maximum size or until at least half of the receiver’s buffer is free Delayed Acknowledgement solution Delay sending Ack. Effect is Sender’s sliding window will not be able to move, hence it will stop sending data Send Ack only after sufficient space is free in receivers buffer, or 500 ms has passed

Error Control Implemented using Ack + timer + retransmission Retransmission Timer or RTO (Retransmission TimeOut) Timer is started when a segment is sent Timer is stopped when the corresponding acknowledgement arrives Otherwise RTO expires In current implementations, a retransmission occurs if the retransmission timer (RTO) expires Or, three duplicate ACK segments have arrived. No retransmission timer is set for an ACK segment.

Rules for ACK transmission (see textbook pg. 466) Rule 1: data segment must be piggybacked (an acknowledgment that gives the next sequence number it expects to receive) with ack to reduce traffic Rule 2 (Delayed ACK, slide 21): receiver has no data to send and it receives an in-order segment, and the previous segment is already ack’ed  delay sending ack for a period of time (normally 500 ms) Rule 3: If there are two in-order unack’ed segments, ack immediately. Fig. 15.29 Normal operation

Rules for ACK transmission (contd.) Rule 4: when a gap occurs (out of order segment with higher sequence number arrives), ACK immediately. Rule 5: When a gap is filled, ack immediately. Rule 6: When duplicate segment arrives, ack immediately. Fig.15.30 Lost segment Retransmit if RTO expired

TCP sender timer events Data received from application: Create segment with sequence no. (number of the first data byte in segment) Start timer if not already running Timeout: Restart timer Retransmit segment that caused timeout ACK received: If ACK is acknowledging previously unACKed segments Update what is known to be ACK’ed Stop timer if all segments have been ack’ed Else, restart timer if there are still outstanding (unack’ed) segments

Rules for ACK transmission (contd.) Rule 4: when a gap occurs (out of order segment with higher sequence number arrives), ACK immediately. Rule 5: When a gap is filled, ack immediately. Rule 6: When duplicate segment arrives, ack immediately. Fig.15.30 Lost segment Ack 601 Outstanding (unack’ed) segment (601-700), Restart Timer Ack 601 Ack 601 Seq 601-700 Ack: x Retransmit if RTO expired

Retransmission In modern implementations, a retransmission occurs if the retransmission timer (RTO) expires or three duplicate ACK segments have arrived No timeout timer is set for ACKs Value of RTO is dynamic and based on RTT (Round Trip Time) of segments

Fast retransmission Rule 4 RTO hasn’t gone off… But 3 duplicate ACKs Rule 4 Rule 4 Rule 5 Rule 4: when a gap occurs (out of order segment with higher sequence number arrives), ACK immediately. Rule 5: When a gap is filled, ack immediately.

Fast Retransmission Time-out period often relatively long: long delay before resending lost segment Sender detects lost segments via duplicate ACKs. sender often sends many segments back-to-back if segment is lost, there will likely be many duplicate ACKs for that segment If sender receives 3 ACKs for same data, it assumes that the segment immediately after ACK’ed data was lost: fast retransmit: resend segment before timer expires

Lost acknowledgment Cumulative acknowledgement Lost ACK not noticed by TCP Next ACK automatically corrects the loss

Lost acknowledgment corrected by resending a segment The last ACK is lost or delayed for a long time Correction is triggered by RTO Receiver discards duplicate segment but resends last ACK immediately by Rule 6: When duplicate segment arrives, ack immediately. Retransmit if RTO expired