1

I wanted to observe the congestion window of a TCP flow so for that I have to nodes (using Linux namespaces) connected to each other through veth pairs and a bridge.

To limit bandwidth to 10mbps I use a htb qdisc in each interface with a queue length of 1000 packets.

Then I set an iperf session between them:

1) You can observe that the bit rate does adapt to the bandwidth the qdisc will shape for us.

2) However checking the pcap file and queues drop counters also see that there are never drops or as an effect retransmissions

If i start a second flow they both get a fair share of 5mbps.

What it is going on here? How is TCP adapting the flow size if there is the congestion control is not getting signals? Am I missing something ?

Improve this question

1 Answer 1

Reset to default
0

You are slowing the transmission inside each host, but you are not actually taking advantage of the TCP flow mechanisms because you are queuing packets instead of losing packets. What you are doing will work even with UDP, which has no flow control mechanism. Instead of queuing, you should use policing (drops) to slow the transmission, then you will see TCP react.

Queuing and shaping are designed to try not to lose packets, but policing purposely drops packets. You could also try something like RED that randomly drops packets in a queue to keep a queue from filling. This will help prevent TCP global synchronization (a bad thing) by taking advantage of the TCP flow control.

If you really want to observe the TCP flow control in action, the do varying tests with different rates of policing.

Improve this answer
6
  • Thanks for your answer Ron. However there is still something I don't understand. Inside the host I queue packets in the htb disc that has a length of 1000 packets, and TCP will increase the window all the time since there are no drops. So the socket will push more packets to the queue, the TCP flow should try to grow until it fills a queue, why is that not happening? In the case of UDP if I have two flows that push into the queue 20mbps and the output rate is 10mbps I will be dropping 5mbps from each flow each second (if the queue has fair queueing like sfq).
    – edgarstack
    Jul 15, 2017 at 20:18
  • RED would drop packets when the queue reaches a threshold, why would RED get filled up to the threshold and my DropTailQueue is not getting full if at some point TCP should send more than the output interface at the host can handle.
    – edgarstack
    Jul 15, 2017 at 20:42
  • You are doing this inside a single PC. Unfortunately, that is off-topic here. We can discuss TCP theory and what happens out on a real network, but technically your question is off-topic. We simply cannot get into the hows and whys of what is actually happening inside a host/server/VM OS. The Unix & Linux site would be more appropriate for that.
    – Ron Maupin ♦
    Jul 15, 2017 at 20:44
  • You are right. But still, I don't understand why TCP is not pushing until it fills Queues in the path to the destination.
    – edgarstack
    Jul 15, 2017 at 20:50
  • It could be something in the OS recognizing that you have shaped to a slower speed, but we can't get into that here, which is why I suggested using policing instead. That will definitely get TCP's attention.
    – Ron Maupin ♦
    Jul 15, 2017 at 20:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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