Random Early Detection Gateway
We were tasked to implement a RED gateway based on the paper by Floyd and Jacobson.
This exercise is to extend the previous work done with FIFO Queue Scheduling. Thus, I used my existing implementation in iOS and replaced the FIFO Queue component with my implementation of the RED Queue Gateway.
The parameters available for configuration in this gateway are the following:
w_q — queueing weight
min_th — minimum threshold
max_th — maximum threshold
maxp—maximum probability for p_b
pkrate—the typical packet rate equivalent to 1/(typical transmission time)
bz—buffer size of the gateway queue
For my experiments I used the following parameters (similar to the test parameters in the paper):
w_q = 0.002
min_th = 5 packets
max_th = 15 packets
maxp = 1/50
pkrate = same as the output rate of the scheduler
bz = 100 packets
For each of my trials I modified the incoming traffic rate and the outgoing traffic rate while keeping the parameters above constant.
- For in_rate <= out_rate, in_rate much greater than max_th (e.g. in_rate = 30 to 50):
The average queue size from RED’s algorithm seems to linger around the maximum threshold value. There are dropped packets since even though the in rate is the same as the out rate, the queue limits the traffic to the thresholds.
- For in_rate <= out_rate, in_rate between thresholds or close to the max threshold (e.g. in_rate = 15 to 20):
There were no dropped packets. It may be because the average queue size does not grow close to the threshold values.
- For in_rate <= out_rate, in_rate <= min_th:
There were also no dropped packets as expected.
- For in_rate > out_rate, any value of in_rate with respect to the thresholds:
We could expect dropped packets. And as expected we do get dropped packets.
The effect of RED should be more pronounced on arrival rates that are varying as it tries to keep the average queue size inside the thresholds.