Tuning TCP Reno parameters to reduce delay experienced by short flows of size 20KB ?

Question

I am trying to tune TCP reno parameters in order to reproduce fig 21 here. The author uses TCP New Reno as congestion control algorithm.

I am tuning the parameters as :

1. rto_min = 10ms
2. Set sender cwnd to 10 using ip route
3. Set receiver rwnd to 10 using ip route
4. Disable slow_start_after_idle
5. Set max rmem and wmem to 16777216
6. ECN is enabled by default

All other options are as default for kernel v 3.19

My Topolgy is as follows : I have two machines connected connected by 1Gbps link to switch (emulate by a machine) and a receiver connected to switch by 1Gbps link. RTT is around 590microseconds.
Switch port connected to receiver operates in drop tail mode with max buffer size as 700KB, achieved using tc-pfifo

I generate traffic using iperf3. I create two long lived flows using iperf3 each from one sender to the common receiver as described in section 4.2.2 . When I start the short flow I get the completion time of the order of 150ms. I understand that the queue is full and hence the packets are being delayed. I also understand that the senders are not using slow start and directly entering congestion avoidance. Is my understanding wrong ? According to the authors the short transfer in case of TCP New Reno must be of the order of 15-35 milliseconds.

Can someone please help me understand where I am going wrong and suggest possible solutions that can help me overcome this problem ?

Answer 1

The above issue was resolved and I was able to reproduce the same figure. The authors specified that for TCP they were using 100 packets as the limit of buffer. And I was using 467 packets as buffer depth. This was the only difference which when corrected gave the results as the author has obtained. No other setting was needed. All default settings were used.

In the whole process I learnt many new things about TCP which were quite interesting.