[ns] Unanimity: RED and DropTail

[Wen Shushan <wenss@uestc.edu.cn>]

Some days ago, I did some simple experiments in order to see the TCP perfomance
through RED gateway when the thresh and buffersize was small. I expected that
if I set RED hard buffer size very small, e.g. 2 pkt, the performance of TCP
connection would be the same as DropTail. But the ns' simulating result was not
coincident my expectation, and the RED's drop rate is much smaller than
DropTail. For example, in one of my simulation, the DropTail queue drops packet
 No.8 (counting in both direction on the duplex link) in the TCP slow start
phase:  
DATA0 -> ACK1 -> DATA2 -> DATA3 -> ACK4 -> ACK5 -> 
 -> DATA6 -> DATA7 -> DATA8 (DROPED) -> DATA9 . . .
But when I only changed the DropTail to RED, the first dropped packet would be
No.20. I can't believe it!
I had to check two files: "red.cc" and "drop-tail.cc". I found there is a
unamimity in the concept of hard buffer size in RED and DropTail.
When a new packet arrives at a drop-tail gateway, it will handle the packet as
follows: 

void DropTail::enque(Packet* p) {
	q_->enque(p);             
	if (q_->length() > = qlim_) {   		
			q_->remove(p);
			drop(p);		
	}
}
 
Firstly, the drop-tail gateway puts the new packet into the queue, regardless of
the queue length before the arrival. Secondly, it calculate the queue length
AFTER the new packet waiting in the queue. 
On the contray, as description in "red.cc", a RED gateway will check its length
before puting a new packet into the queue.
So, the buffersize in RED is 1 packet larger than DropTail even they have the
same value! And if the value is too small, the difference in performance will
conspicuous.
I changed the ">=" in "drop-tail.cc" to ">", and avoided the unanimity.

Regards!

Wen Shushan