| title | Computer Networks Programming Assignment 3 |
|---|---|
| author | Alexander Myers |
Github: https://github.com/CosmicOriginDev/ComputerNetworks-Programming-Assignment-3
The experiment was ran in Oracle Virutalbox emulating Ubuntu version 18 (Bionic Beaver). The vm has 6 cores and 8GB RAM.
Two different network profiles were tested. A High-Latency Low-Bandwidth environment(rtt 200ms, bandwidth 1Mpbs) A Low-Latency High-Bandwidth environment(rtt 10ms, bandwidth 50Mpbs) I chose to compare the BBR, Cubic, and Vegas algorithms. Each experiment used 1 flow and ran for 60 seconds.
One way delay (x2 to get RTT)
This graph plots a time series which shows the packet delay over time.
It looks like the large spikes coincide with packet losses.
The spikes where there are delay are very thin. This means that the delays do not persist for very long.
|
Throughput
This graph plots a time series which shows the throughput over time.
The throughput remains decently high most of the time and there are occasional drops which coincide with packet losses.
|
95th percentile per-packet one-way delay: 103.453 ms
Loss rate: 0.46%
One way delay (x2 to get RTT)
This graph plots a time series which shows the packet delay over time.
The spikes where there are delay are wider This means that the delays persist a bit longer.
|
Throughput
This graph plots a time series which shows the throughput over time.
The throughput is barely visible, meaning this is not a good protocol for high-latency low-bandwidth links.
|
95th percentile per-packet one-way delay: 105.127 ms
Loss rate: 0.91%
One way delay (x2 to get RTT)
This graph plots a time series which shows the packet delay over time.
The spikes where there are delay are wider This means that the delays persist a bit longer.
|
Throughput
This graph plots a time series which shows the throughput over time.
The throughput is barely visible, meaning this is not a good protocol for high-latency low-bandwidth links.
|
95th percentile per-packet one-way delay: 105.498 ms
Loss rate: 0.73%
Cubic and Vegas are pretty awful for a high-latency low-bandwidth link because they have high delay and low throughput.
BBR is awesome for this though, it has low delay and high throughput.
|
One way delay (x2 to get RTT)
This graph plots a time series which shows the packet delay over time.
The wide bands show that BBR's delay times are all over the place.
There are also large delay spikes that have a cyclic pattern.
Overall BBR is not a good protocol for a low-latency high-bandwidth link.
|
Throughput
This graph plots a time series which shows the throughput over time.
We see large random drops in throughput, but the throughput remains high for the most part.
|
95th percentile per-packet one-way delay: 97.032 ms
Loss rate: 0.15%
One way delay (x2 to get RTT)
This graph plots a time series which shows the packet delay over time.
Cubic has the worst delays of any of the protocols in this link.
|
Throughput
This graph plots a time series which shows the throughput over time.
Cubic also seems to have trouble with reciving packets, but not with sending them.
We see that the line for reciving packets (ingress) seems to have points where the throughput drops to almost zero.
However the line for sending packets (egress) seems to be using up all the bandwidth.
|
95th percentile per-packet one-way delay: 1305.356 ms
Loss rate: 2.06%
One way delay (x2 to get RTT)
This graph plots a time series which shows the packet delay over time.
The delays gradually decrease over time which is a great thing for any protocol.
|
Throughput
This graph plots a time series which shows the throughput over time.
This algorithm fills up the capacity, meaning it is a good algorithm for a Low-Latency High-Bandwidth link.
|
95th percentile per-packet one-way delay: 356.935 ms
Loss rate: 0.36%
All three are pretty middle of the road for a low-latency high-bandwidth link.
Cubic has high throughput and high delay.
BBR has low throughput and low delay.
Vegas has high throughput and medium delay.
So overall Vegas is the best out of these three.
|
- Which algorithm is more aggressive or latency-friendly?
BBR is the best for high-latency and low-bandwidth.
Looking at this graph, you will see BBR is in the top right corner.
This indicates that it has the lowest delay and the highest throughput.
- Does any scheme persistently overshoot the link capacity?
Actually all three do during the low-latency high-bandwidth test.
BBR
|
CUBIC
|
VEGAS
|
The tan box on each graph represents the link capacity. At some point, each of the algorithms overshoot that tan box.
- Are there excessive losses or large queues with certain parameters?
There are no excessive losses, the largest one is only 2%.
We see that in a low-latency high-bandwidth environment, Cubic seems to be reciving more packets than the link can handle.
This would cause large queues.
- Do you have enough information to assess which protocols are the best-performing?
No.
I only measured 3 of the many protocols that come with Pantheon.
The links that I simulated in Mahimahi drop so few packets that it is hard to see a difference.
- What was the most challenging part of the assignment?
The most difficult part of this lab was installing Pantheon and Mahimahi.
To be honest, this was the most frustrating CS project I have ever worked on.
And that's really saying something when that's coming from me because I usually find troubleshooting to be a fun challenge.
I have worked on this part almost non-stop for several days.
There was an issue where Pantheon's c++ scripts had errors in them that prevented them from compiling.
I figured that I should not have to change the c++ scripts. So I tried checking the packages over and over and over and over.
You know how it feels when you think you are just one step away from getting something working and it ends up taking 4 hours.
There was one day where I had that sort of thing for 10 HOURS STRAIGHT.
After several days I could not get pantheon to work.
I posted my error messages on slack and Victor was kind enough to help me.
We tried rebuilding Pantheon and it still did not work.
I was not sure if it was my vm or if it was a problem with pantheon.
So I asked Victor to send me his pantheon folder and it worked.
I don't know why pantheon was not working before, and I wish I could have figured out the issue by myself.
I think I was really close, but we all know what would have happened if I would have kept trying to build it from source.
Dispite all of this, I learned a lot from this lab:
I am now a pro at using a vm and reinstalling linux (Because ChatGPT runied my linux install so many times).
I know how to use python environments.
I know how to build things from source.
I learned how to write bash scripts.
And I am so proud of myself for sticking with it as long as I had.
I really hope the next homework is easier than this one.
- If you used LLMs, explain how. What do you think you were going to learn better without LLMs and what do you think helped you learn faster?
I used ChatGPT to help me get Pantheon and Mahimahi running.
ChatGPT just did the boring copy paste stuff like installing the god knows how many packages.
ChatGPT was also good for helping me fix syntax errors.
At one point I was so exhausted that I just mindlessly copy pasted from ChatGPT for the install and it bricked my vm several times.
So moral of the story, I need to take breaks!
ChatGPT got me most of the way there but I had to troubleshoot without it for some parts.
Nothing about this project was learning fast. It was slow and painful. It would have been 10 times worse without ChatGPT.
- With whom (human e.g., other students, TA) did you discuss your solutions?
Christine, Anthony, Carly, Emra, Chris, Camille, Terrell, and Victor.