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 ?

  • 1
    When you fill a tail-drop queue, arriving packets aren't slowed, they are completely dropped. This can result in TCP synchronization, where all senders slow, then speed up at the same time, repeating the process. The is havoc for TCP. Using RED will randomly drop packets in the queue to keep the queue from filling to prevent synchronization.
    – Ron Maupin
    Apr 29, 2016 at 4:53
  • @Ron Maupin Thanks for your answer. However the authors are using drop tail queue, hence I have to use the same, in order to reproduce the same effects.
    – akadam
    Apr 29, 2016 at 5:24
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Aug 14, 2017 at 2:18

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.