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

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

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

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

5. 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

6. 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

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

8. 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

9. 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.

10. Fig 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.

11. Fig 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.

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

13. 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 ≥
The receiver needs to wait until more buffer is free before sending ack

14. 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

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

16. 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.

17. 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

18. 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) = ( ) – ( ) = 100
1001

19. 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

20. 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

21. 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

22. 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.

23. 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
Normal operation

24. 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

25. 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

26. 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 ( ), Restart Timer
Ack 601
Ack 601
Seq
Ack: x
Retransmit if RTO expired

27. 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

28. 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.

29. 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

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

31. 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