3

I am simulating a network where I limited and modified all the interfaces using TC (traffic control). My interfaces are of the form HTB --- SFQ (it is a little bit more complex but I will simplify that).

The interfaces are limited to 10mbps. Let's say that I send a UDP flow from A to B at 7mbps. After that, from the same host (A), I send a TCP flow to B. Since I have a SFQ at the output interface and there are two flows the scheduler sends 5mbps of each one. So, just to start, the UDP flow will lose 2mbps of bandwidth.

Of course this is what you expect from the Fair queue, you want it to send a fair amount of packets from each flow it sends. However, I would expect the UDP flow taking 7mpbs and the TCP adapting at 3mpbs after some ACK timeouts. But, I never see a timeout. If I remove the SFQ queue, everything is as I expected TCP flow gets 3mpbs and UDP 7mbps.

Is that normal? Is that what I should expect? If this is the normal behaviour I should expect, that would mean that for any given path if there is a big TCP flow, you can only use 50% for UDP traffic if you do not want to have losses.

Is there a solution for that keeping the SFQ queue?.

3

This is expected. SFQ enforces the fairness which TCP/TCP-friendly only approximate when contending for limited bandwidth. If some traffic should get more than its fair share, you need to classify it as such and bypass the contended SFQ instance. That's what HTB is for (as opposed to the classless TBF).

This is a common strategy. There are worked examples out there, I just never have them to hand when I want them. Typically the bandwidth of the higher priority class will be bounded, to avoid completely starving other traffic.

https://wiki.archlinux.org/index.php/Advanced_traffic_control#Hierarchical_Token_Bucket_.28HTB.29

http://lartc.org/howto/lartc.qdisc.filters.html

Please remember that some UDP traffic is designed as TCP-friendly, e.g. QUIC. If you literally filter on UDP traffic then downloads from Chrome nightlies could potentially saturate the high-priority bandwidth. That would not make sense from the point of view of fairness.

Also you almost certainly want to replace SFQ with FQ_CODEL. Test the load-induced latency e.g. with http://dslreports.com/speedtest, or simply ping during one of your saturation tests. (There's one interesting caveat. "Background" traffic using uTP works by keeping induced latency lower than 100ms. Using CODEL or similar to clamp latency lower than this, uTP flows effectively become foreground traffic and contend for the same share of bandwidth as TCP).

|improve this answer|||||
  • I am already using HTB queues before the SFQ, to classify control traffic and some special flows. I am not sure if I want to give priority to UDP flows over all the TCP, it will increase a lot the completion time of long TCP flows. However I would reduce the huge drop UDP flows experiment with the presence of TCP elephant flows. – edgarstack Aug 20 '16 at 12:11
  • 1
    Would that really be any different to SFQ allowing the UDP traffic to maintain 7 mbps as you had expected (and the same result in the absence of SFQ)? – sourcejedi Aug 20 '16 at 12:20
  • Yes you are right, if I do that I would be doing fair queuing only for TCP (which is somehow fair and adapts to the bandwidth given). So it would be as if I had no SFQ. – edgarstack Aug 20 '16 at 12:28

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.