- Common practice:
- A frame (message)
that was received corrupted
is discarded
Reason:
- Since we do not know
which part of the
fame (message) was in
error,
it would be foolish to
try to
use any part of the
message
Hence: the entire frame (message) is discarded
- Since we do not know
which part of the
fame (message) was in
error,
it would be foolish to
try to
use any part of the
message
- A frame (message)
that was received corrupted
is discarded
- Transmission:
- A sender
will send data frames to
a receiver
- A receiver
will send acknowledgement frames to
a sender
- A sender
will send data frames to
a receiver
- Note that:
- Both a data frame and an acknowledgement frame can be lost (= received in error)
- Consider the following
protocol to
achieve
reliable transmission:
- Sender:
- Sender
transmits a frame
and wait for an acknowlegdement
of its reception
before
transmitting the
next frame
- If the sender has not receive
an acknowledgement
for some (pre-defined)
time:
- the sender will time out and retransmits the same frame.
- If the acknowledgement is
received
within the timeout period,
the sender can transmit the next
frame
- Sender
transmits a frame
and wait for an acknowlegdement
of its reception
before
transmitting the
next frame
- Receiver:
- When receiver receives a
correct frame,
it sends back an
ACK frame (message)
- The receiver will deliver a received frame (to the user (program))
- When receiver receives a
corrupt frame (= bad CRC),
it sends back
nothing
- This is because the receiver will
treat a corrupt frame (= bad CRC)
as not receiving any frame)
(See argument at the start of this webpage: click here)
- This is because the receiver will
treat a corrupt frame (= bad CRC)
as not receiving any frame)
- When receiver receives a
correct frame,
it sends back an
ACK frame (message)
- Sender:
- Example: how the protocol
operates when there are
no errors
Comments:
- Sender sends the first frame containing xxx
- Receiver sends back an acknowledgement frame when xxx is received.
- Sender receives the acknowledgement frame and then sends the second frame containing yyy
- Receiver sends back an acknowledgement frame when yyy is received.
Conclusion:
- Receiver will deliver the transmitted frames exactly once and in the correct sequence.
- Analyzing any
protocol:
- The protocol must work under
different circumstances:
- Must work when there are no errors
(obviously...)
- Must work when there are errors in data frames (messages)
- Must work when there are errors in acknowledgement frames !!!
- Must work when there are no errors
(obviously...)
- The protocol must work under
different circumstances:
- Example 1 :
transmission error in the
data frame
Comments:
- The sender transmits the
first data frame
containing xxx
- When the receiver
receives the frame and
determines the frame is
in error (bad CRC),
the receiver
will discard the
corrupted frame
- The receiver will
not transmit
any acknowledgement frame
(In fact, the receiver cannot transmit an acknowledgement frame --- because if the sender receives an acknowledgement frame, the sender will think that the frame xxx was received correctly !!!
- The receiver will
not transmit
any acknowledgement frame
- The sender will
time out and
retransmit
the same message
- The time, the receiver recived it
correctly and
transmits
a acknowledgement frame
- The sender transmits the
first data frame
containing xxx
- Conclusion:
- The basic protocol can recover from the transmission error in frames from the sender
- Example 2 :
transmission error in the
acknowledgement frame
Comments:
- The sender transmits the
first data frame
containing xxx
- When the receiver
receives the frame,
the receiver
transmits
a acknowledgement frame
- The acknowledgement frame
is corrupted and
the sender will assumed
that that it did
not receive any
acknowledgement frames !!!
Consequently:
- The sender will time out and transmit the first frame again !!!
- The time, the receiver received
the
duplicate first frame and
deliver the frame:
- The frame xxx is delivered multiple times !!!!
Conclusion:
- The basic protocol
cannot ensure
reliable communication
- Remember that
reliable communication means:
- All messages received exactly once
- (And in the same order as they were transmitted)
- The sender transmits the
first data frame
containing xxx
- Recall:
- The receiver can
receive the
same frame
multiple times:
To fix the problem, we must first understand the cause !!!
- The receiver can
receive the
same frame
multiple times:
- What is the
cause of the
problem:
- The receiver
cannot tell
that the second transmission
was a duplicate transmission
(of a frame that it has
already received)
(Frames cannot be distinguished by their content !!!
Sometimes, different frames cantain the same content !)
- The receiver
cannot tell
that the second transmission
was a duplicate transmission
(of a frame that it has
already received)
- The fix:
- make each frame
distinguishable by:
- Numbering each frame with a different send number
Example:
- make each frame
distinguishable by:
- Add
an sequence number
(contained in
the message header part)
in the message
sent by the sender:
- To recognize
the awaited frame,
the The receiver
keeps a receive sequence number:
- The receiver will
accept a frame for delivery
if the sequence number
in the frame
is equal to
its receive sequence number:
When the receiver accepts a frame, it must also send an ACK frame !!!
- A message with a
different sequence number
is not accepted (= discarded):
However, the receiver must send an ACK frame, because otherwise, the sender will keep sending the same frame again:
- Operation
of the improved basic protocol:
- Sender:
- Set Send Seq. No. = 0
- Send data frame with the given Send Seq. No.
- Wait for an ACK frame
- If ACK frame received
before time out:
- Increase Send Seq. No.
- Transmit the next data frame
otherwise
- Retransmit data frame
- Receiver:
- Set Send Seq. No. = 0
- When receiver receives a
data frame:
- If Send Seq. No. in frame
is equal to
Recv. Seq. No.:
- Accept the data frame
- Increase the Recv. Seq. No.
- Send an ACK frame
Otherwise:
- Discard the data frame
- Send an ACK frame
- If Send Seq. No. in frame
is equal to
Recv. Seq. No.:
Examples
- When there are no errors,
the sender and receiver will
operate like this:
- The receiver can
now detect
duplicate frames:
- Sender:
- Question:
- Can the improved protocol
ensure reliability ???
(I.e: Messages delivered once and in the same order as sent)
Answer:
- No !!
There is one more kind of error that we have not yet considered !!!
- Can the improved protocol
ensure reliability ???
|
|
- 3 things that can happen to an
ACK frame:
- An ACK frame can be
lost
(A corrupted ACK frame is counted as lost)
- An ACK frame can be received
in time
(i.e., before time out)
- An ACK frame can be received after time out !!!!
(The reason why an ACK frame can be late is because receiver was busy with some other task.)
- An ACK frame can be
lost
- How can a
delayed ACK frame
cause error in
the reliable communication:
Explanation:
- Sender's
frame 0 is received
- Receiver send
ACK late !!
- The ACK frame arrives after the sender has timed out !
- Sender will
time out and
retransmits frame 0
- In the mean time, the
ACK for the first
frame 0 is
received:
- The sender accepts the
ACK and
sends
the next frame:
frame 1
- Frame 1 is corrupted (i.e., not received by receiver)
- The sender accepts the
ACK and
sends
the next frame:
frame 1
- The retransmitted frame 0 is
received correctly
- Receiver will
discard the
retransmitted frame 0,
but will send
an ACK frame !!!
- When the sender receives this ACK frame (intended to ACK the retransmitted frame 0), it erroneously believes that the ACK frame was an ACK for frame 1 !!!
- Sender's
frame 0 is received
- The cause of this
confusion:
- The sender
has mis-identified the frame
of an ACK frame (message)
- The receiver wanted
to acknowledge
frame 0
- The sender believed that the ACK frame to acknowledges frame 1
- The receiver wanted
to acknowledge
frame 0
- The sender
has mis-identified the frame
of an ACK frame (message)
- Fixing the
duplicate ACK problem:
- Make sure an ACK frame will acknowledge a specific frame !!!
Implementation:
- Add an sequence number in the ACK frame (in the frame header) sent by the receiver
- After including the
2 modification
to the basic protocol:
- Add a Send Sequence Number to the data frames (messages) and
- Add a Receive Sequence Number to the ACK frames
the resulting protocol is the well-known Stop-and-Wait protocol.
- Initializing the
Stop-and-Wait
protocol:
- Sender and
receiver
must first agree on the
same sequence number
(This can be done by resetting both sender and receiver sequence number to 0 (zero) when the link is resetted)
- Sender and
receiver
must first agree on the
same sequence number
- Sender:
- Send a frame with the
current sequence number x
- Wait for
for an ACK frame
containing the
sequence number x
- If the ACK x frame
is received before the time out,
increase the
current sequence number
to
x+1
- If sender receives an ACK frame with a wrong seq. no., it discard the ACK frame.
- Otherwise, retransmit the frame with the same sequence number x
- If the ACK x frame
is received before the time out,
increase the
current sequence number
to
x+1
Note: a corrupt ACK frame is discarded
- Send a frame with the
current sequence number x
- Receiver:
- When receiver receives a
data frame,
the receiver
check
the sequence numbers:
- if the
frame's sequence number x ==
receiver's
receive sequence number y,
then:
- Accept the data frame (and deliver it to the user)
- Send a ACK frame y to the sender
- Increase receiver's receive sequence number (to y+1)
- Otherwise:
- Discard the data frame
- Send a ACK frame x to the sender
- if the
frame's sequence number x ==
receiver's
receive sequence number y,
then:
Note: a corrupt data frame is discarded
- When receiver receives a
data frame,
the receiver
check
the sequence numbers:
- Example:
when there are
no erros,
the
the sender and receiver will operate like this:
- How
the Stop-and-Wait
protocol solves the
Duplicate ACK problem:
- Recall that the sender
believed that
the delayed ACK
acknowledges
frame 1:
- The Stop-and-Wait protocol
solves the duplicate ACK problem
as follows:
Explanation:
- When the receiver receives the
duplicate frame 0,
the receiver sends
ACK 0 that
contains
the seq. no. 0
- When the sender receives
the ACK 0,
the sender can tell
the this ACK does
not acknowledge the
data frame 1
- In the above scenario, (because the frame 1 is lost), the sender will timeout and retranmits the frame 1 again (and recover correctly)
- When the receiver receives the
duplicate frame 0,
the receiver sends
ACK 0 that
contains
the seq. no. 0
- Recall that the sender
believed that
the delayed ACK
acknowledges
frame 1:
- The complete name of the
Stop-and-Wait protocol is:
- Stop-and-Wait
Automatic Repeat reQuest
protocol
Or: Stop-and-Wait ARQ protocol
Wikipedia page: click here
- Stop-and-Wait
Automatic Repeat reQuest
protocol
- ARQ protocols:
- ARQ protocl =
a family of
error-control methods
for data transmission that uses
acknowledgements
and
timeouts
to achieve
reliable data transmission
over an unreliable transmission medium.
Wikipedia page: click here
- ARQ protocl =
a family of
error-control methods
for data transmission that uses
acknowledgements
and
timeouts
to achieve
reliable data transmission
over an unreliable transmission medium.
- The Stop-and-Wait ARQ protocol
is the simplest member of
the ARQ protocols
- We will study a more
complex and
more efficient
ARQ protocol
next:
- The Go-back-N ARQ protocol