- Recall: the cause
of the error
- The receiver
cannot tell
whether a frame is:
- A re-transmission or
- A now transmission
- The receiver
cannot tell
whether a frame is:
- Proposed
fix
- Make each data frame
distinguishable by:
- Adding a unique send sequence number to each data frame
Example:
- Make each data frame
distinguishable by:
- Assumption:
- For now, let us
assume:
- We can use an infinite number of different sequence numbers
Note:
- This assumption will make
the protocol
easy to
understand and
prove
- We will fix (drop) this assumption later
- For now, let us
assume:
- Assumption:
- Sender and receiver are initialized with the same Frame#
- Consider the following
modified protocol to
achieve
reliable transmission:
- Sender:
Start: Transmit frame with send seq no = Frame#; Set a timeout; while ( not timeout && ACK not received ) { Wait for ACK frame; } if ( timeout expired ) { go to Start; } Frame# = Frame# + 1; Done; (ACK was received !)
- Receiver:
// Receiver is ready to receive frame number R Receive frame; if ( CRC check is OK ) { /* ---------------------------------------------- Receiver must only deliver new data frames ---------------------------------------------- */ if ( send seq no == R ) { Send ACK frame to sender; // ACK the new frame Deliver frame; R = R + 1; // Accept next new frame } else { // An OLD frame was received !!! Send ACK frame to sender; // Correct lost ACK frame error !!! Discard frame; // because it's an old frame } } else { // Bit errors !!! Discard frame; }
- Sender:
- Example:
error-free operation
According to the modified protocol:
- Sender transmits data frame
with Send seq no = 4
- Sender sets a timeout for frame
- Receiver receives the
data frame with
matching Frame#:
- Receiver transmits a ACK frame
- Receiver increments R = 5 !!!
- Receiver delivers the data frame
- Sender receives the ACK
frame
before
timeout expires
- Sender increments Frame# = 5 !!!
- Done !!!
- Sender transmits data frame
with Send seq no = 4
- Scenario 1 :
transmission error in the
data frame
According to the modified protocol:
- The sender transmits
data frame
with send seq no = 4
- Sender sets a timeout for frame
- Data frame is
lost (bit error(s))
- Receiver will not transmit an ACK frame !!!
- The sender will
time out:
- Sender will retransmit the same frame
- The receiver receives
Frame and
send seq no == Frame#:
- Receiver transmits a ACK frame
- Receiver increments R = 5 !!!
- Receiver delivers the data frame
- Sender receives the ACK
frame
before
timeout expires
- Sender increments Frame# = 5 !!!
- Done !!!
- The sender transmits
data frame
with send seq no = 4
- Conclusion:
- The modified protocol can
recover:
- Data frame transmission errors !!!
- The modified protocol can
recover:
- Scenario 2 :
transmission error in the
acknowledgement frame
According to the modified protocol:
- Sender transmits data frame
with Send seq no = 4
- Sender sets a timeout for frame
- Receiver receives the
data frame with
matching Frame#:
- Receiver transmits a ACK frame
- Receiver increments R = 5 !!!
- Receiver delivers the data frame
- ACK
frame
is
lost and
the sender will
timeout
- Sender re-transmits Frame# = 4 !!!
- Sender transmits data frame
with Send seq no = 4
- The re-transmission is
processed as follows:
According to the modified protocol:
- Sender transmits data frame
with Send seq no = 4
- Sender sets a timeout for frame
- Receiver receives the
data frame with
mismatched Frame#
:
- Receiver transmits a ACK frame (recovers lost ACK !!!)
- Receiver discards the data frame (duplicate !!!)
- Sender receives the ACK
frame
before
timeout expires
- Sender increments Frame# = 5 !!!
- Done !!!
Correct !!!
- Sender transmits data frame
with Send seq no = 4
- Reason why
an ACK frame
can be late:
- The receiving device is slow
- The receiver was temproally overloaded (busy with other tasks)
- Error scenario 3:
how an
last ACK frame
can
cause error in
reliable communication:
Explanation:
- Sender transmits data frame
with Send seq no = 4
- Sender sets a timeout for frame
- Receiver receives the
data frame with
matching Frame#:
- Receiver transmits a ACK frame
- Receiver increments R = 5 !!!
- Receiver delivers the data frame
But the ACK frame is delayed
- The sender will
time out:
- Sender will retransmit the frame #4
- The sender receives
the delayed ACK:
- Sender increments Frame# = 5 !!!
- The sender now
transmits a new frame with
send seq no = 5
- Sender sets a timeout for frame
This new data frame is lost !!!
- In the mean time, the
re-transmission of
frame #4 is
received at the
receiver
The receiver finds send seq no ≠ 5 and detects (correctly) that it is an old frame:
- Receiver transmits a ACK frame
- Receiver discards the data frame (duplicate !!!)
- The sender receives
the ACK frame:
-
Sender increments
Frame# = 6 !!!
(Sender thinks that data frame #5 has been received !!!)
Error !!!
-
Sender increments
Frame# = 6 !!!
- Sender transmits data frame
with Send seq no = 4
- Right now,
we cannot
fix the
protocol error
because:
- The sender
cannot
distinguish
between these
2 different cases:
- An acknowledgement for an new data frame
- An acknowledgement for an old data frame
- Graphically explained:
- Case 1:
the first ACK
for frame 4 was
lost:
The 2nd received ACK acknowledges the new frame (#5) correctly !!!
Remember that the sender will only "see" these events:
- Case 2:
a delayed
ACK frame was
used to
acknowledge the
wrong data frame:
Remember that the sender will only "see" these events:
- Case 1:
the first ACK
for frame 4 was
lost:
- The sender
cannot
distinguish
between these
2 different cases:
- Fixing the
delay/duplicate
ACK problem:
- The receiver
adds
a recv sequence number
to identify
each ACK frame
uniquely
- The recv sequence number in an ACK frame must identify the data frame that it is "acking"
- The sender will use the recv sequence number in the ACK frame to check whether a data frame is acked
- The receiver
adds
a recv sequence number
to identify
each ACK frame
uniquely