0. CMPT 371 Data Communications and Networking
Principles of reliable data transfer

1. Fast Retransmit
For sliding windows flow control we waited for a timer to expire before beginning retransmission of a packet
TCP uses an additional mechanism based on cumulative acknowledgement to reduce the wait time for retransmission
This fast retransmit mechanism keeps track of the retransmitted cumulative ACKs arriving at the source.
If the same cumulative ACK arrives four times (three retransmissions), indicating that there is missing data at the destination then the source automatically retransmits the packet starting with the next octet expected by the receiver.
Janice Regan ©

2. Sliding Window: fast retransmit5 6 7 1 2 3 4 F0 5 6 7 1 2 3 4 F1 5 6 7 1 2 3 4 5 6 7 1 2 3 4 F2
ACK1 5 6 7 1 2 3 4 F3 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK1 F4 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK1 F5 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK1 F6 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK1 F1 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK1 5 6 7 1 2 3 4
ACK7 5 6 7 1 2 3 4 5 6 7 1 2 3 4
Janice Regan ©

3. Reliable underlying network: 1
Allow each end to know the other exists
Negotiate of optional parameters (segment size, window size, QoS)
Allocation of transport entity resources (buffer space, entry in connection table)
Need ESTABLISHED (open), CLOSED, and ‘half open’ states. Process must be ‘listening’ to accept a connection
Need two types of messages (socket subroutine calls)
SYN: specifies initial sequence numbers for synchronization
FIN: indicates no more data to send, requesting termination
Janice Regan ©

4. Reliable underlying network (2)
‘half open’ states occur when opening or closing a connection
connection requested and not yet established (SYN SENT) (waiting for response SYN)
ready to accept connections no request received yet (LISTEN) (waiting for initiating SYN, will immediately respond with response SYN)
Close requested, data flow from requesting endpoint is complete (FIN WAIT) (waiting for response to sent FIN)
Close request received, data flow from endpoint receiving close request continues until completion (CLOSE WAIT) (waiting to respond to close request, FIN)
Janice Regan ©

5. Connection State Diagram
Stallings 2003: Figure 20.3
Janice Regan ©

6. Connection Establishment
Lost or delayed data segments can cause connection problems if the previously discussed 2-way handshake is used
Cannot assume sent SYN or FIN reaches destination
Arriving SYN or FIN could be from an old connection attempt
Solve by using a three way handshake (must ACK receipt of FIN or SYN) and start segment numbers (SYNi, ACKi, FINi) far removed from those used by previous connections
Janice Regan ©

7. Unreliable Network Service
ADDITIONAL PROBLEMS
Solved by using variants of sliding windows (hybrid of go back N or selective reject) and credit scheme already discussed
Segments may get lost, need retransmission strategy
Duplication detection
Flow control
Segments may arrive out of order, transport layer must deliver in order to application (solution unique sequence numbers)
Connection establishment / termination (replace two way handshake with three way handshake to deal with losses, duplications)
Janice Regan ©

8. Ordered Delivery Segments may arrive out of order
Number segments sequentially
TCP numbers each octet sequentially
Segments numbers indicate the by the first octet number in the segment
Flow may not start with octet 0 (helps distinguish between different connections)
Janice Regan ©

9. Connection Establishment
Lost or delayed data segments can cause connection problems if the previously discussed 2-way handshake is used
Cannot assume sent SYN or FIN reaches destination
Arriving SYN or FIN could be from an old connection attempt
Solve by using a three way handshake (must ACK receipt of FIN or SYN) and start segment numbers (SYNi, ACKi, FINi) far removed from those used by previous connections
Janice Regan ©

10. Unreliable underlying network
Must add additional states to the diagram
When opening need a SYN RECEIVED state to be in while waiting for the ACK of the SYN sent in response to the SYN sent by the initiating station
When closing in passive mode need a LAST ACK state to be in while waiting for the ACK of the FIN sent in response to the received FIN
Janice Regan ©

11. Unreliable underlying network
When closing in active mode need
FIN WAIT2 state to be in while waiting for the station receiving the close request (the first FIN) to complete transmission and send response FIN. The ACK of the first FIN is received before entering this state
CLOSING state to be in while waiting for the ACK to the response FIN. The response FIN has already been received before entering this state
Janice Regan ©

12. Three Way Handshake Active Open: CLIENT CLOSED SYN_SENT LISTEN
Passive Open: SERVER
CLOSED
LISTEN
SYN_SENT
ESTABLISHED
Send SYN
Close
(Timeout)
Receive SYN-ACK
Send ACK
Receive SYN
Send SYN-ACK
SYN_RECEIVED
Receive ACK of SYN
Janice Regan ©

13. Three Way Handshake: ESTABLISHED FIN_WAIT_1 FIN_WAIT_2 TIME_WAIT
Send FIN
FIN_WAIT_1
FIN_WAIT_2
Receive FIN
Send Ack
Receive FIN-ACK
Receive ACK of FIN
TIME_WAIT
CLOSING
CLOSED
CLOSE_WAIT
LAST_ACK
Timeout
Janice Regan ©

14. Structure of a TCP packet
Variable length header: from 20 bytes (no options) to 60 bytes
SOURCE PORT
DESTINATION PORT 20
CHECKSUM
Janice Regan ©

15. Flow Control and Error control
Flow may be controlled because:
The receiving transport layer entity can not keep up and runs out of buffer space
The receiving application layer process can not accept data fast enough and data must remain in transport buffer for longer
Longer transmission delays between transport entities than for a direct physical connection
Delay in communication of flow control info
Variable transmission delay make definition and use of timeouts problematical
Janice Regan ©

16. When to send ACKs Use sliding window flow control
Start by considering the simplest part of the problem and assume a reliable underlying network (delivery guaranteed)
When do we send the ACK after receiving a segment
Conservative approach is to send ACK only when buffer is available, to avoid buffer overflow
Optimistic approach send ACK so next data will arrive when buffer is available. Flow will resume more quickly after congestion, but data may be lost
Janice Regan ©

17. Optimistic approach
ACK is sent when segment is received by the transport entity at the receiver,
When the ACK is received by the source the source is free to send another packet
This may cause buffer overflow at the receiver because
The transport layer buffers the segment until the data in the segment can be successfully transferred to the application layer
It is possible that the transfer (due to loading at the receiver’s host) will be slow.
The application may not be ready to accept the additional data when it arrives.
Janice Regan ©

18. Buffer overflow example
Consider a system with source and receiver both having a sliding window that holds 100 octets. The source in this system sends segments each holding 25 octets.
The source sends segment 1, the receiver receives segment 1
The receiver sends an ACK for segment 1
The source sends segments 2, 3, and 4, the receiver receives them
The receiver is extremely busy and the data in segment 1 remains in the receiver’s receive buffer.
The source receives the ACK1 and sends segment 5.
Segment 5 arrives at the receiver, the receiver has not finished sending segment 1 to the application
The data in segment 5 overwrites the data for segment 1 and will be sent to the application as segment 1
Janice Regan ©

19. Conservative approach
ACK is sent when segment has been transferred to the application layer
When the ACK is received by the source the source is free to send another packet
Thus, the buffer at the receiver already has space before the ACK is sent no overflow occurs
However in a congested network significant time may be wasted waiting for ACKS
If the delays due to congestion are significant unnecessary retransmission may also occur and further contribute to the congestion problems
Janice Regan ©

20. Improving Sliding Windows
Flow may be controlled because:
The receiving user can not keep up (runs out of buffer space)
The receiving transport entity can not keep up
Control Flow using one of the following approaches:
Conservative: send ACK only when buffer is available, to avoid buffer overflow
Optimistic: send ACK so next data will arrive when buffer is expected to be available. (data may be lost and require retransmission)
Credit mechanism: decouple ACK from control of sliding window buffer
Janice Regan ©

21. Credit allocation mechanism
The choice of when to ACK a packet can be addressed by using a credit allocation mechanism which separates acknowledgement of receipt from moving the sliding window
Each ACK contains two values
One indicates the next packet expected
One indicates the amount the sliding window can be moved
An ACK can be sent immediately after receipt of a packet, the sliding window need not be moved at the same time.
When the receiver can handle additional data, an additional ACK can be sent to move the window
Janice Regan ©

22. Sliding window: credit allocation
Changes to the source window happen after ACK is received
Changes to the receiver window happen after the ACK is sent
An ACK can combine acknowledgement of any number of packets ending with packet m with granting credit for n packets (for any n>=0)
Janice Regan ©

23. Sliding window: receipt
Send/receive ACKm without credit allocation
After the receipt of ACKm
the start of source window slides to the right to the beginning of packet m. All packets up to packet m-1 have been successfully received and need not be kept in source buffer
After sending ACKm the receiver location of window is unchanged
Janice Regan ©

24. Sliding window: credit allocation
ACKm with only credit allocation of n packets
After the receipt of the ACK the end of source window slides to the right n packets
After sending the ACK the receiver window (both ends) slides to the right n packets
Janice Regan ©

25. Credit Mechanism: 1
All frames of data in transit must be buffered in the sliding window at the source until the ACK from the receiving station arrives at the sending station.
Source transmits frames from its sliding window until its send buffer is exhausted. Think of each frame as having a timer to indicate how long to wait for the ACK.
Receiver receives a frame and
Sends an ACK , indicates next frame expected and any credit allocation
Advances the left end of its sliding window past the end of the acknowledged data
Advances the right end of its sliding window by the amount of the credit allocation (if any) given in the ACK it sent
Janice Regan ©

26. Credit mechanism: 2
Source entity receives ACK and stops timer for acknowledged frame.
If an ACKm is received the source entity
advances the end (right end) of its sliding window by the amount of credit granted (n frames)
Advances the start (left end) of its sliding window to the beginning of the next frame (frame m) expected by the receiver
If a timeout timer expires the frame with an expired timer is retransmitted and the timer is reset
Janice Regan ©

27. Sliding Window with credit allocation: problem?5 6 7 1 2 3 4 F0 5 6 7 1 2 3 4 F1 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK1
CRED0 F2 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK2
CRED1 F3 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK3
CRED0 F4 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK4
CRED0 F5 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK5
CRED3 F6 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK6
CRED2 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK7
CRED1 F7 5 6 7 1 2 3 4
Janice Regan ©

28. Credit Mechanism: 1 (fixed)
All frames of data in transit must be buffered in the sliding window at the source until the ACK from the receiving station arrives at the sending station.
Source transmits frames from its sliding window until its send buffer is exhausted. Think of each frame as having a timer to indicate how long to wait for the ACK.
Receiver receives a frame and
Sends an ACK , indicates how long the senders window should be
Advances the left end of its sliding window past the end of the acknowledged data
Advances the right end of its sliding window by the amount of the credit allocation (if any) given in the ACK it sent
Janice Regan ©

29. Credit mechanism: 2 (fixed)
Source entity receives ACK and stops timer for acknowledged frame.
If an ACKm is received the source entity
Advances the start (left end) of its sliding window to the beginning of the next frame (frame m) expected by the receiver
advances the end (right end) of its sliding window to make the window the same length as it told the sender to make its window
If a timeout timer expires the frame with an expired timer is retransmitted and the timer is reset
Janice Regan ©

30. Sliding Window with credit allocation5 6 7 1 2 3 4 F0 5 6 7 1 2 3 4 F1 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK1
Window5 F2 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK2
Window5 F3 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK3
Window4 F4 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK4
Window3 F5 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK5
Window5 F6 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK6
Window6 5 6 7 1 2 3 4 5 6 7 1 2 3 4
ACK7
Window6 F7 5 6 7 1 2 3 4
Janice Regan ©

31. One more question
Do you see any other problems in the previous example?
Our cycle of window numbers is not long enough
If we send 6 segments, receive no ACKs for any of the 6 segments, then resend the six segments, the receiver will think the resent packets 0, 1, 2, 3 are the from the next cycle
Just like for selective repeat need a window that is <=N/2 where N is the length of our numbering cycle
So for a window of length 6 need a cycle of at least 12, cycle length should be 2N so use 16
Janice Regan ©

32. Sliding Window with credit allocation5 6 7 8 9 10
113
124
135 14 1 2 3 4 15 16 11 12 13 F0 5 6 7 8 9 10 11 12 13 14 1 2 3 4 15 16 F1 5 6 7 8 9 10 11 12 13 14 1 2 3 4 15 16 5 6 7 8 9 10 11 12
135 14 1 2 3 4 15 16
ACK1
Window5 F2 5 6 7 8 9 10 11 12 13 14 1 2 3 4 15 16 5 6 7 8 9 10 11 12 13 14 1 2 3 4 15 16
ACK2
Window5 F3 5 6 7 8 9 10 11 12 13 14 1 2 3 4 15 16 5 6 7 8 9 10 11 12 13 14 1 2 3 4 15 16
ACK3
Window4 F4 5 6 7 8 9 10 11 12 13 14 1 2 3 4 15 16 5 6 7 8 9 10
113 12 13 14 1 2 3 4 15 16
ACK4
Window3 F5 5 6 7 8 9 10 11 12 13 14 1 2 3 4 15 16 5 6 7 8 9 10 11 12 13 14 1 2 3 4 15 16
ACK5
Window5 F6 5 6 7 8 9 10 11 12 13 14 1 2 3 4 15 16 5 6 7 8 9 10 11 12 13 14 1 2 3 4 15 16
ACK6
Window6 5 6 7 8 9 10 11 12 13 14 1 2 3 4 15 16 5 6 7 8 9 10 11 12 13 14 1 2 3 4
157 16
ACK7
Window6 F7 5 6 7 8 9 10 11 12 13 14 1 2 3 4 15 16
Janice Regan ©