Experiment 4: Nice with RED queueing

We repeat experiments 1 and 2, but with routers performing RED queueing. The RED parameters are set as recommended in  [23] with the ``gentle'' mode on. The minimum and maximum RED thresholds are set to one-third and two-third of the buffer size. Packets are probabilistically marked with ECN support from the senders. Figure 6 plots the foreground document transfer latency against the spare capacity with 16 background flows. Though Nice still performs as much as an order of magnitude better than other protocols, it causes up to a factor of 2 increase in document transfer latencies for large spare capacities. As figure 7 indicates, under RED, Nice closely approximates router prioritization regardless of the number of flows when the spare capacity is one, i.e. the demand workload consumes half of the network capacity.

The relatively poor performance of Nice under RED when spare capacities are large appears to reflect the sensitivity of Nice's interference $I$ to bottleneck queue length (Equation 1). Whereas Nice flows damage foreground flows when drop-tail queues are completely full, under RED, interference can begin when the bottleneck queue occupancy reaches RED's minimum threshold $min_{th}$. One solution may be to reduce Nice's $threshold$ parameter. The Nice-0.03 lines in Figures 6 and 7 plot Nice's interference under RED when $threshold = 0.03$ instead of the default value of $0.10$. Future work is needed to better understand Nice's interaction with RED queuing.