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

2. Transport Layer Common protocols TCP and UDP
UDP is best effort, no reliable delivery
TCP insures reliable delivery
Remember the Transport layer is above a network layer that does provides an unreliable transmission channel
TCP must compensate for the underlying unreliable channel to provide reliable transmission. This makes TCP much more complicated
Janice Regan © Sept

3. Best Effort Delivery (Error free)
Coordinate the amount of data that can be sent
Data must arrive at the receiver no faster than it can be processed
No flow control (UDP, best effort transmission):
Send data and hope receiver can process fast enough or buffer.
Slowing send speed enough to ensure reception will reduce utilization (efficiency) of the link
Janice Regan © Sept

4. Design of protocols Consider what TCP needs to do
Many things, overwhelming to think about how the design was done?
Let’s start simple and work up to see how protocols can be designed
For a first try let’s and make the assumption that the underlying communication channel is reliable
We have a sending host and a receiving hosts, what rules should they follow? How to design a protocol?
We are sending data from source to destination (unidirectional protocol)
Janice Regan © Sept

5. Finite State Machine Source Receiver reliable channel, no flow control
From initial state
From initial state
IDLE
Waiting for data
from application
IDLE
Waiting for data
from network
layer segment
To final state
Build segment
send segment
extract data
deliver to application
To final state
Janice Regan © Sept

6. Our first protocol
If correct delivery of segments is guaranteed out protocol will work
What sort of problems might occur
Source host is transmitting too fast for the destination host to receive and process segments
Data segments arrive (that’s guaranteed) they can be corrupted during transmission
Next let us consider how to take care of these possible problems above in our protocol
Janice Regan © Sept

7. Want a reliable transmission
If we have a completely reliable channel we know all segments arrive, we do not need this confirmed, so our first protocol would work
Realistic channels will have bit errors so we will want to know if the segment arrived without being corrupted in any way.
First step to being able to verify if the segment arrived without corruption is to verify that the segment arrived
Janice Regan © Sept

8. Stop and Wait ARQ Reliable Delivery
ARQ: Automatic Retransmission Request
ERROR FREE CASE
Source entity (sender), S1, transmits segment
Destination entity (receiver), S2, receives segment
Destination entity sends acknowledgement
Source entity receives acknowledgement
Source entity is now ready to start the cycle again
Janice Regan © Sept

9. Stop and Wait ARQ: error free
Send F
Send ACK
Send F
Send ACK
Send F
Send ACK
Send F
Send ACK
Send F
Send ACK
Send F
Send ACK
Send F
Send ACK S1 S2
Error Free Transmission
Janice Regan © Sept

10. Finite State Machine: Stop and Wait
ARQ reliable channel (no errors or loss, segments acked)
Source
Receiver
extract data
deliver to application
Build ACK
Send ACK
From initial state
From initial state
Made and sent segment
IDLE
Waiting for data
from application
WAIT
Wait for ACK
IDLE
Waiting for data
from network
layer segment
Received ACK
To final state
To final state
Janice Regan © Sept

11. Error Free Stop and Wait: Utilization (1)
S1 sends frame F1 which takes time tFRAME to transmit
tFRAME = (Length of Frame) / (Data Rate) = L / R
F1 reaches S2 after propagating for time tPROP
tPROP = (Propagation Distance) / (Propagation Velocity) = d/V
F1 is queued and processed by S2 in time
tQF + tPROCF
Janice Regan © Sept

12. Error Free Stop and Wait: Utilization (2)
S2 sends an acknowledgement (ACK) which takes time tACK to transmit
The ACK reaches S1 after propagating for time tPROP
S1 queues and processes the ACK in time tPROCA+tQA
The total time to send one frame of data is
Tt = tFRAME + tPROP + tPROCF + tQF
+ tACK + tPROP + tPROCA+ tQA
Janice Regan © Sept

13. Error Free Stop and Wait: Utilization (3)
Utilization, U, is the fraction of the total available transmission time, Tt, that is used to transmit data.
The total time to send N frames of data is
Ttot = N × { tFRAME + tACK + ( 2 × tPROP ) + tPROCF + tQF
+ tPROCA + tQA }
The total time spent transmitting N data frames is
Tf = N × tFRAME
The link utilization, U, of the channel in the absence of errors and losses is
U = Tf / Tt = Tf / (Tf + RTT)
Janice Regan © Sept

14. Want a reliable transmission
Realistic channels will have bit errors so we will want to know if the segment arrived without being corrupted in any way.
Now we can acknowledge a correct segment
Next let’s add a negative acknowledgement for a segment that arrives with bit errors
We are still assuming that there are few errors so we can still recognize that the corrupted segment is a segment
We are still assuming no segments are lost
Janice Regan © Sept

15. Stop and Wait ARQ: bit errors
Source entity (sender), S1, transmits a frame
Destination entity (receiver), S2, receives a frame
Destination entity processes the frame and finds that there are bit errors in the frame
Destination entity sends an NACK to indicate the contents of the segment have not arrived intact, and drops the segment
Source entity receives the NACK
The source entity resends the same segment
Janice Regan © Sept

16. Stop and Wait ARQ: bit errors
Damaged frame (incorrect data): problems with NACK
Must know address is correct to use NACK mechanism
If there are bit errors this may not be a good idea, the bit errors may be in the address field we do not know
For now assume this is not a problem
Stop and wait with NACK F
ACK F X
Frame with bit errors arrives
NACK F
ACK F
ACK F
ACK
Janice Regan © Sept

17. FSM: Stop and Wait No segment loss, no corrupted ACKs /NAKs
For transmission in a channel in which bit errors may occur in segments
Receiver
Source
Segment corrupted
Build NACK
Send NACK
From initial state
From initial state
segment Made and
Transmitted:
IDLE
Waiting for data
from network
Layer
IDLE
Waiting for
data from
application
WAIT
Waiting for
ACK or NACK
To final state
Received
ACK:
Segment not corrupted
extract data
deliver to application
Build ACK, Send ACK
Received NACK:
Retransmit the same segment
To final state
Janice Regan © Sept

18. Want a reliable transmission
Realistic channels will have bit errors so we will want to know if the segment arrived without being corrupted in any way.
Now we can acknowledge a correct segment, or send a NACK to acknowledge a corrupted segment and cause it to be resent
But what happens if an ACK or a NACK is corrupted?
Janice Regan © Sept

19. Possible solutions
Use checksum and error correction with enough bits to correct a reasonable number of errors
Would work if no segment ever had more that the specified number of bit errors (dangerous assumption)
Would work if no segments were ever lost.
We know with best effort delivery segments can be dropped by intermediate routers and not get to the destination at all
Request resending of ACK ? This is an infinite progression, each resent ACK can be corrupted and in turn need to request retransmission
Janice Regan © Sept

20. Better Solution
Retransmit the last segment sent when a corrupted ACK or NACK segment is received.
Sending host knows which segment was sent last so it can resend the correct segment
PROBLEMS
When the resent segment arrives at the destination, the destination assumes it is the next segment, not a copy of the previous segment
We need to use sequence to fix this problem. For now two numbers 1 and 0 will do
Janice Regan © Sept

21. Stop and Wait ARQ: bit errors
Damaged ACK or NACK (incorrect data): possible solution 1
When the receiver receives a corrupt segment it sends a NACK
When the sender receives a corrupted segment it resends the last segment sent
When the resent segment reaches the destination it is the second copy of that segment received
Use sequence number to tell if it is the same segment as the last one received (new segment or retransmission)
Stop and wait with NACK F0
ACK F1
ACK X
ACK with bit errors arrives F1
ACK F0
ACK F1
ACK
Janice Regan © Sept

22. FSM: Source (no segment loss)
in a channel in which bit errors may occur in ACKs, segments
From initial state
IDLE 0
Waiting for data
from application
Received NACK or
Corrupted ACK/NACK
Retransmit segment
WAIT
Waiting for
ACK or NACK
Make and Transmit
segment: F0
Received ACK:
Received NACK or
Corrupted ACK/NACK
Retransmit segment
Received ACK:
WAIT
Waiting for
ACK or NACK
IDLE 1
Waiting for data
from application
Make and Transmit
segment: F1
Janice Regan © Sept

23. Finite State Machine: Receiver
in a channel in which bit errors may occur in ACKs, segments
Received F1
Make and Send ACK
From initial state
Received F0
Make and Send ACK
IDLE 0
Waiting for data
from network
Layer
Receive segment: F0
Deliver Data
Make and send ACK
IDLE 1
Waiting for data
from network
Layer
Receive segment: F1
Deliver data
Make and send ACK
Received corrupted segment
Send NACK
Received corrupted segment
Send NACK
Janice Regan © Sept

24. Stop and Wait ARQ: bit errors
Damaged ACK or NACK (incorrect data): possible solution 2
When the receiver receives a corrupt segment it sends an ACK for the last segment received without error
When the sender receives duplicate ACK it knows the previous segment did not arrive at the destination and can resend the lost segment
Need to use sequence numbers for ACKs as well as for data segments
No problem if error is in address
Stop and wait with NACK F0
ACK0 F1
ACK 1 X
ACK with bit errors arrives F1
ACK 1 F0
ACK 0 F1
ACK 1
Janice Regan © Sept

25. FSM: Source (no segment loss)
in a channel in which bit errors may occur in ACKs, segments
From initial state
IDLE 0
Waiting for data
from application
Received ACK1 or
Corrupted ACK
Retransmit segment
WAIT
Waiting for
ACK 0
Make and Transmit
segment: F0
Received ACK 1:
Received ACK 0 or
Corrupted ACK
Retransmit segment
Received ACK 0:
WAIT
Waiting for
ACK 1
IDLE 1
Waiting for data
from application
Make and Transmit
segment: F1
Janice Regan © Sept

26. Finite State Machine: Receiver
in a channel in which bit errors may occur in ACKs, segments
From initial state
IDLE 0
Waiting for data
from network
Layer
Receive segment: F0
Deliver Data
Make and send ACK 0
IDLE 1
Waiting for data
from network
Layer
Receive segment: F1
Deliver data
Make and send ACK 1
Received corrupted segment
Or receive F1
Send ACK 1
Received corrupted segment
or receive F0
Send ACK 0
Janice Regan © Sept

27. Stop and Wait ARQ Utilization: (1)
If errors and losses make retransmissions necessary then
U = Tf / ( Nr × Tt )
If no timers expire, Nr,, is the average number of transmissions per frame, Na. Otherwise Nr is a function f(Na)
Let Pf be the probability that a given frame contains errors.
The probability that it will take i attempts to transmit the frame is
The average number of retransmissions, Na, is the sum for all possible values of the number of transmissions needed multiplied by the probability that that number of transmissions will be needed
Janice Regan © Sept

28. Stop and Wait ARQ Utilization: (2)
Assume that no ACKs or NACKs are lost or damaged, and that the timeout timer never expires
Then Nr is the average number of transmissions per frame and the channel utilization is
Also assuming that
Processing time is negligible
The acknowledgment frame is small compared to the data frame .
U = (1-Pf )Tf / Tt
U = (1-Pf ) / (1+2a)
Janice Regan © Sept

29. Want a reliable transmission
We have accounted for a channel with minimal bit loss (even with incorrect bits in address)
Now consider what happens if the segment is so corrupted we can not identify it as a segment, or if the segment does not reach the destination.
We know that an acknowledgement should arrive about 1 RTT after sending a segment. If it does not arrive we will assume the segment did not arrive or the acknowledgement was lost
Janice Regan © Sept

30. Timeout (lost segments or ACKs)
Source entity (sender), S1, transmits a frame and starts a timer
Destination entity (receiver), S2, receives a frame
Destination entity sends an ACK
Source entity receives ACK and stops timer
Source entity is now ready to start the cycle again for a new frame
If timer expires before the source entity receives the ACK from the destination entity repeat the steps above for the same frame
Janice Regan © Sept

31. Stop and Wait : problems
Possible problems caused by errors
Damaged frame (corrupted data)
Lost frame (not received)
Damaged / Lost ACK
Delayed ACK
Send F0
Send ACK0 *
Send F1
Send F1
Send ACK1
Send F0 *
Send ACK0
Send F0
Send ACK0
Send F1
Send ACK1
delayed
Send F1
Send ACK1
Transmission with losses and errors
Janice Regan © Sept

32. Stop and Wait ARQ: lost segment
Lost Frame
Must wait for timeout
No NACK would be sent, segment did not arrive
Stop and wait: lost frame F1 F0 *
ACK0
Timeout
expired
ACK1
Janice Regan © Sept

33. Stop and Wait ARQ: lost ACK
Lost Frame or ACK
Must wait for timeout
Damaged / Lost ACK causes duplicate reception of frame.
Alternate labeling of frames F1 and F0 allows for identification of duplicates F1 F0
ACK0
ACK1 *
Timeout
expired
Stop and wait:
lost ACK and duplicate frame
Janice Regan © Sept

34. Stop and Wait ARQ delayed ACKF0
Delayed ACK
Must wait for timeout
Delay in sending ACK causes duplicate reception of ACK by Sender.
Alternate labeling of frames F1 and F0, and ACKS, ACK0 and ACK1 allows for identification and elimination of duplicates. Without it ACKs may be mismatched with frames, and a later lost frame may go undetected.
ACK0 F1
Delay
sending ACK
Timeout
expired
delay F1
ACK1 F0
ACK1
ACK0
Stop and wait: duplicate ACK
Janice Regan © Sept

35. Finite State Machine: Source
in a channel in which bit errors and segment loss may occur
From initial state
Received ACK1 or
Corrupted ACK/NACK
Received
segment
IDLE 0
Waiting for data
from application
WAIT
Waiting for
ACK 0
Timeout expired
Retransmit segment
Reset timer
Make and Transmit
segment: F0
Received ACK 0
Stop timer:
Received ACK 1
Stop Timer:
IDLE 1
Waiting for data
from application
Timeout Expired
Retransmit segment
Reset Timer
WAIT
Waiting for
ACK 1
Received
segment
Received ACK 0 or
Corrupted ACK/NACK
Make and Transmit
segment: F1
Janice Regan © Sept

36. Stop and Wait Utilization: examples (1)
Assume protocol has the following properties
Processing and queuing time are negligible
(tQF ≈ 0, tQA ≈ 0, tPROCF ≈ 0, tPROCA ≈ 0)
The ACK frame is small compared to the data frame
(tFRAME >> tACK or tFRAME + tACK ≈ tFRAME )
No errors or losses
Janice Regan © Sept

37. Stop and Wait Utilization: examples (2)
The maximum link utilization, U, is
U = Tf / Tt
= tFRAME /{ tFRAME + tACK + ( 2 × tPROP )
+ tPROCF + tPROCA }
= tFRAME / { tFRAME + 2 × tPROP } = 1 / (1+2a)
Where
a = tPROP / tFRAME = ( R × d ) / ( V × L )
Janice Regan © Sept

38. Preview of TCP
TCP uses cumulative ACKS similar to those in this protocol
TCP’s uses ACK numbers that indicate the next segment (octet) it expects to receive, not the last segment (octet) it has already received
Janice Regan © Sept

39. Stop and Wait : problems TCP
Possible problems caused by errors
Damaged frame (corrupted data)
Lost frame (not received)
Damaged / Lost ACK
Delayed ACK
Send F0
Send ACK1 *
Send F1
Send F1
Send ACK0
Send F0 *
Send ACK1
Send F0
Send ACK1
Send F1
Send ACK0
delayed
Send F1
Send ACK0
Transmission with losses and errors
Janice Regan © Sept