TCP Traffic Generator

We were tasked to add TCP-like behaviour in our previous work.

There are different flavours of TCP but I chose to implement a one that follows congestion control similar to TCP Reno. When the generator detects congestion, via an acknowledgement of a dropped packet, I set the generator window to half. When I successfully send a packet, I increase the window size by 1/(currentWindowSize). My implementation of TCP generator also has a sequence number that resets to the previously successfully routed packet after it receives a negative acknowledgement.

I limit the amount of packets sent and take the time it takes for all the packets to be routed. I use the previous article’s parameters for the RED Queue. Then I vary the in rate and out rate for the network. I compare the total transfer time with that of the FIFO Queue.

Total transfer time for 2500 packets to transfer, out_rate = 15, in_rate = 15:

• RED Queue: 24 seconds
• FIFO Queue: 18 seconds

It seems like it takes longer for a TCP transfer to complete when the gateways are RED enabled. Although I think RED was not meant for faster transfers. It was designed to control congestion. We can measure its effectiveness by measuring the average queueing delay.

To measure I put timestamps on each packet, when it gets added to the queue. Then compute the delay when it it about to be routed. The delay gets into a running average computation and stored in a variable. The average queueing delay of 100 samples is computed until the transfer completes.

Average queueing delay, for 2500 packets to transfer, out_rate = 15, in_rate = 15:

• RED Queue: 0.024
• FIFO Queue: 0.15

As we can see the RED Queue has shorter queueing delay resulting from a shorter average queueing size.