Λίστα με τα μαθήματα Συνδεθείτε

Information

Author(s) Anthony Doeraene et Louis Navarre
Deadline 15/05/2024 20:00:00
Submission limit No limitation

Συνδεθείτε

Συνδεθείτε

QUIC and congestion control lab

Follow the instructions from https://github.com/Aperence/linfo1341-congestion-student/tree/main/lab .

Answer to the questions below with the different scenarios from the git.

Question 1: ACK clocking

In this first scenario, we start with a simple example: what happens when QUIC sender has no congestion control scheme, but uses a constant sending window ? With this much information, it might be difficult to know what will result from this. Let us add an hypothesis: the client sends at a rate of ~2Mbps, as it has a sending window of 10000 bytes, and a round-trip time of 40ms.

What do you observe? Was there any problem during the transmission?

Question 2: Is ACK clocking sufficient?

Now that we have seen what happens with a fixed sending window transmitting at a smaller rate than the bottleneck bandwidth, let us see what happens when fixed sending window results in a rate that is greater than the bottleneck bandwidth. To do so, we will configure QUIC to transmit at a rate of 80Mbps (sending window of 400000 bytes, and a round-trip time of 40ms).

How did ACK clocking perform compared to CUBIC?

Question 3: Stepping up: sharing bandwidth between two clients

Let us now see what happens when 2 clients send data at the same time and have to share the ressources. You can try different combinations (Reno-CUBIC, Reno-Reno and CUBIC-CUBIC) transactions and see what happens.

Is the bandwidth shared fairly? And how does the cwnd of the 2 congestion control algorithms evolve?

Compare Reno vs Reno, Reno vs Cubic, and Cubic vs Cubic.

Question 4: When someone use an unfair congestion control algorithm...

Up to now, we've seen how you can use a congestion control algorithm to share bandwidth and have a fair repartition of ressources. But what should we do when someone has a faulty congestion control algorithm and/or doesn't want to share ressources. Many companies would want to be able to use the network alone without being bothered by the actions of other people. Let us see what happen when someone tries to always send at a high rate, and how it affects the other people in the network.

What do you see? Is that a fair share of the bandwidth?

Question 5: ...but the router saves the day
The endhosts are not the only ones who can influence the rate of transmission in a network. Routers also have a huge influence on the rate a flow may transmit. Perhaps, dropping the last packet arrived is not a perfect solution, so let's try using a fair queue. To do so, we'll add on router1 a fair queue, using the fq_codel algorithm. Answer to the following questions by mentionning Explicit Congestion Notification (ECN). This tool allow use to use a deficit round robin on different queues, and the incoming flows may be put in different queues based on the hash of their ip-port couple. Let us observe now how the bandwidth is shared between the 2 hosts.

What do you see? Is this still as unfair?

Question 6: Effect of RTT on transmission rate

Up until now, we have seen how the different congestion controllers behave while having a constant RTT. A question we could ask ourselves is "Does the RTT have any influence on the transmit rate ?".

What do you see? Does Reno with a longer RTT takes more time to send the same amount of data? How does it (or not) affect the growth of cwnd? Same questions for CUBIC.

Question 7: Wait, are you lagging?

As the last scenario of this lab, we will analyze how different congestion control algorithms behave facing large round-trip-times.

Which one does perform the best under long rtt situation? Why is this the case?