|
Labsheet 3 - for the week commencing 18th March 2024
REDUCE YOUR FRUSTRATION - UNDERTAKE THIS LABSHEET WITH A FRIEND.
-
[1-2 hours]
[files required:
stopandwait.c,
STOPANDWAIT1
]
In
Lecture 3
we introduced the stop-and-wait Data Link Layer
protocol, which delivers frames between directly connected hosts.
We also recognized that the nature of stop-and-wait results in a lot
of time being 'wasted', particularly in the presence of Physical Layer errors.
In
Labsheet 2
we observed that employing negative-acknowledgments can
reduce the waiting time, resulting in an increased data throughput.
Another mechanism to improve stop-and-wait is to piggyback
acknowledgments onto data frames.
Each frame now carries two sequence numbers:
a frame travelling from A→B
may include a sequence number describing data
being carried from A→B
and may include another sequence number acknowledging data previously
sent from B→A.
The benefit is that fewer frames need to traverse 'the wire',
and fewer frames interrupt each network interface-card and operating system.
The implementation of piggybacking is a modification to stop-and-wait:
- When the receiver gets a DL_DATA frame,
it does not immediately send an DL_ACK frame.
- The receiver waits (for a limited time)
until it has its own outgoing DL_DATA frame to send,
and piggybacks the pending DL_ACK in the outgoing header.
- If no DL_DATA frame becomes available in a short time,
the receiver must send an DL_ACK frame by itself.
For this task, using the cnet network simulator:
- Add piggybacking to the standard stop-and-wait protocol.
- Modify the topology file,
changing the attributes of message delivery, bandwidth,
frame corruption and loss,
to determine under which conditions piggybacking offers an advantage.
- To perform a valid scientific experiment
(which, after all, is what we're doing),
we need to hold all conditions/arrtibutes constant and vary just one over time,
perform the same experiment for both the stop-and-wait and
piggybacking protocols.
As in
Labsheet 2,
develop a plot to help you to visually compare the results of your experiment.
The easiest approach is to use the
plot-to-html.sh
shellscript used in
Labsheet 2
to plot multiple curves on the same graph
(you may like to learn about the 'join' program to merge the results
of the two simulations).
- [HARDER 1-2 hours, and requires reading a textbook]
🌶
🌶
Sliding-window protocols are
Data Link Layer protocols that support multiple outstanding frames between
sender and receiver.
Again, the goal is to minimize the waiting time required in the standard
stop-and-wait protocol.
In general, sliding-window protocols have the properties that:
- the sender has a sending window
consisting of a sequence (an array) of frames that have been
sent but not acknowledged.
- The sender's window size grows as more frames are sent
but not yet acknowledged.
- The receiver has a receiving window
consisting of frames it is willing to accept.
The receiver's window size remains constant.
- Each frame being sent has a sequence number from 0 to 2n-1
(which fits in >n bits). Stop-and-wait has n=1.
- A window size of 1 implies that frames are only accepted
in order,
and thus an error is detected if an expected frame is missed
(a 'later' frame arrives first).
The simplest variant of a sliding-window protocol is termed
the go-back-N protocol,
in which the receiver simply discards (ignores) all frames after a bad one.
This corresponds to a receiver window size of 1.
After it learns of a lost (or corrupted frame),
the sender retransmits all unacknowledged frames -
it "goes back N frames" and starts again.
Notice that in the presence of significant errors that
bandwidth is wasted because the receiver only 'buffers' a single frame.
Following the same experimental approach as in the first task,
use cnet to implement the go-back-N protocol,
and determine under which conditions it is an improvement over the
stop-and-wait protocol.
Chris McDonald
March 2024.
|