CITS3002 Computer Networks - Labsheet 3  
 

Unit home

help3002

Lecture recordings
via LMS

Schedule

Unit outline

Resources

Textbooks

Extra reading



Look after yourself!

Labsheet 3 - for the week commencing 18th March 2024

REDUCE YOUR FRUSTRATION - UNDERTAKE THIS LABSHEET WITH A FRIEND.

  1. [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 AB may include a sequence number describing data being carried from AB and may include another sequence number acknowledging data previously sent from BA. 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.

  2. 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).

  3. [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.

The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Presented by [email protected]