1

I am testing our client-server applications using NetLimiter which is a traffic control software. I found that, when client is receiving files from server and I use NetLimiter to set the download rate to a value such as 50K/S by clicking buttons continually (to increase the rate from 0K/s to 50K/s, every click increases the rate by 1), then the transfer will stop and never resume, it seems some control packets from the server are lost.

Will the traffic control software intercept packets and hold them without sending to our client due to unkown reason? Will the traffic control software drop tcp packets which are supposed to send to our client?

[More] The traffic control software does break the transfer because our server will send some control packets to the client to control the transfer, e.g. stop the transfer or start the transfer. And during the tests we found that the "Start the transfer" control packet has arrived at the Network Interface Card but the packet was not received by our client (there is a TCP socket).

Thanks

Steve Peng
  • 509
  • 1
  • 8
  • 18

1 Answers1

4

In short, Yes traffic control software can indeed drop packets when shaping traffic. That's ok for TCP protocols as TCP will take care of ensuring that lost packets get resent.

The Traffic Shaping Wiki describes some of the methods used to shape the traffic. There are many algorithms available such as RED, tail drop and others.

Will the traffic control software intercept packets and hold them without sending to our client due to unkown reason?

It will hold (queue) them for a while before sending in order to ensure the specifically configured rate is met.

Will the traffic control software drop tcp packets which are supposed to send to our client?

Yes, e.g. you may be routing between two networks where one network is shaped to 50KB/s and the other side may be 100KB/s. If 100KB/s of data were sent continuously to a host on the 50KB/s network, then packets need to be held in the router to meet the 50KB/s rate. As memory is limited and queue sizes often fixed there becomes a point where you may have to start dropping packets. Dropping packets isn't a bad thing. TCP is designed to recover. If you were to queue up everything this could be a bad as it can add significant latency. So dropping packets is sensible.

[More] The traffic control software does break the transfer because our server will send some control packets to the client to control the transfer, e.g. stop the transfer or start the transfer. And during the tests we found that the "Start the transfer" control packet has arrived at the Network Interface Card but the packet was not received by our client (there is a TCP socket).

I hate to say it but it sounds like your client server app is the thing that's broken. Dropped packets over the internet is normal expected behaviour.

What are being lost are your control commands. It sounds like a software bug has gobbled them up!

hookenz
  • 14,132
  • 22
  • 86
  • 142
  • Matt, thanks so much for help. We set the download rate to 5k/s, and the problem reproduces everytime. We don't kown how long will it hold the packets? If it is longer than expected than our client will drop the broken packets, e.g. suppose the packet is of size 1K and is now queued by the traffic software, but this software sent out only 500 bytes to our application while keeping the remaing for long time such as 5 minutes, then our application will timeout then drop the first 500 bytes. – Steve Peng May 23 '13 at 11:13
  • One more thing to mention, we have udp video conference and TCP file transfer at the same time. The video conference remains ok, but the control packets for file transfer lost frequently, we don't know if it is being held by the traffic software or has been lost forever . – Steve Peng May 23 '13 at 11:16