# Laboration report #1

By Carl Pryssgård and Max Agnesund

## Introduction

The purpose of this laboratory exercise was to introduce us students to the simulator software that the teacher provided us with.
In order for us to get a proper introduction to the structure of the program we were tasked with implementing a lossy link to extend the simulation with network impairments such as packet loss, delay and jitter.

The first objective was to understand and use the simulator aswell as how to properly add and extend the necessary code.

The second task was to introduce delay and jitter on the lossy link aswell as packet loss meaning it should also drop packets based on a random probabilty.

## Method

I will provide both the simulator program aswell as the code used in order perform this lab below:

[Link to the used simulator software](https://ltu.instructure.com/courses/16918/files/2821567?module_item_id=276237) (Requires access to LTU canvas page D0021E)

### Naive link

import sim.Event;
import sim.Link;
import sim.Message;
import sim.SimEnt;

import java.util.ArrayList;
import java.util.Random;

public class LossyLinkNaive extends Link {
    private static final int JITTER_CONSTANT = 10;
    private int delay_ms;
    private int jitter;
    private double dropProbability;

    /**
     * @param delay_ms How long to wait in ms
     * @param jitter The timeunit for jitter
     * @param dropProbability The probability of dropping a packet (specify me soon)
     */
    public LossyLinkNaive(int delay_ms, int jitter, double dropProbability) {
        this.delay_ms = delay_ms;
        this.jitter = jitter;
        this.dropProbability = dropProbability;
    }

    // Computes jitter in a naive way.
    private float getJitter() {
        if (jitter == 0) {
            return 0;
        }
        
        return new Random().nextFloat(jitter) * JITTER_CONSTANT;
    }

    @Override
    public void recv(SimEnt src, Event ev) {
        System.out.println("Received on the lossy link");

        int total_delay = delay_ms;

        // the jitter component can be computed as a random value multiplied by some constant,
        // this is pretty naive and is why this is the naive lossy link.
        // add the jitter component to `total_delay`
        total_delay += getJitter();


        // randomly drops the packet.
        boolean should_drop = dropProbability != 0 && new Random().nextDouble(1) <= dropProbability;
        if (should_drop) {
            System.out.println("----- DROPPING PACKET -----");
            return;
        }

        // sleep `total_delay` seconds by 
        // letting the simulator wait `total_delay` 
        // before treating the event.
        _now = total_delay;

        super.recv(src, ev);
    }
}

This code extends the `Link` class provided in the simulator. This makes a lot of sense since we are *extending* the already provided `Link` class to now be lossy.
The delay component was implemented by using the simulator's event engine, which in turn has a builtin delay for events.
By using this delay (`_now`) we can *delay* before the simulator will fire off the specific event.
The jitter was then implented by randomly computing a value to add to the delay.
Implementing the packet loss is trivial after this since there should just be a random number generated and compared against the provided `dropProbability`.

### Dynamic link
Alongside this naive link we theorized and tried to implement a more dynamic link.
This new, dynamic link would use a `cur_jitter` variable added to the total delay as with the naive link, the difference is that `cur_jitter` would be set to a specified value (instead of being random like in the naive implementation). The exact value of `cur_jitter` can be argued about but we figured a good middleground to start from would be the given desired jitter (`target_jitter`) divided by `2`.
The goal for the dynamic link was for `cur_jitter` to randomly adjust untill it reached a value sufficient for the link to reach a all-time jitter of `target_jitter`.

## Result
Our result is a lossy link implemented by extending the given simulator utilizing the builtin systems of said simulator. This lossy link introduces a random amount of jitter as well as delays and random packet drops.

## Discussion

During the process of thinking of a proper solution to the task at hand there were multiple choices we could make on how we wanted to implement our ``LossyLink``. There was the naive option which had an easier implementation phase and required us to only understand how to use the different components of the software and how `delay`, `jitter` and `packet loss` worked.

The other option was a more dynamic approach where we could calculate the variation of delay per a specific link in order to achieve the target jitter given at initialization time for the `LossyLink`.

### The naive implementation
We implemented the naive solution to a start by simply generating a random value to add to our `delay`.
However, this naive solution does not account for negative jitter (packets arriving earlier than the delay specified).
We considered and reasoned that the delay given to the lossy link should *always* be respected, e.g it should be treated as the minimum possible delay.
It could however easily be reasoned that jitter should override this respect due to the stochastic nature of jitter in real networks. This negative jitter could easily be implemented by weighting the random number generation differently.

There is also the mathematical aspect to consider when we calculated the amount of `delay` that we might want to have added. When considering calculating the `d_TOT` for our program specifically we came to the conclusion that the most probable of the variables that makes `d_TOT` is `propagation delay`.

### The dynamic implementation
The dynamic implementation was not successfull, this is most likely due to bad starting numbers being chosen alongside bad limits for the random numbers meant to push `cur_jitter` towards the `target_jitter`.
The dynamic version seemed to reach the targeted jitter value for each *individual* packet but failed to realize the `target_jitter` for the entire link when looking at it's jitter over it's entire lifetime.

A reason that this might not have worked was that we did not account for the fact that to reach `target_jitter` over the links lifetime `cur_jitter` needed to average out to something a bit below that due to the start value.

The lifetime jitter of the dynamic link can be calculated by taking all the delays that the link has experienced and taking the mean difference between them.

### The type of delay produced in the simulation
Since we are working in a closed system with only a simulator running and no noise has been introduced to the program during the time of execution so the signal the only probable execution delay that was not specifially programmed by us therefore is most probable `propagation delay`.
To make our simulation account for each type of delay we could introduce more events into the simulator which delay at different points in the program.