2 ms·
I don't understand his description of why SFQ + TBF is disastrous. "Well, given that SFQ has inserted a whole bunch of fairness into the queue and the packets a
by gjm11 16y ago
I don't understand his description of why SFQ + TBF is disastrous. "Well, given that SFQ has inserted a whole bunch of fairness into the queue and the packets are no longer bursty... your interactive session has about a 50% chance of having its packet dropped by TBF." But, er, the situation he's talking about is one where your interactive session contributes only 1% of the packets, and no matter how much fairness SBQ inserts it can't make the next packet as likely to be from your interactive session as not.
The reduced burstiness seems more relevant: suppose your bandwidth hog session is only using 10x more packets than your interactive one overall, but it's using them in bursts; then "when there's been too much data lately" that's probably because you're in a burst of bandwidth-hoggery, so there's much less than a 1/10 chance that the next packet is from your interactive session.
Only, that doesn't quite make sense, because for the bandwidth hog to be hurting your interactive session the latter needs to be trying to send/receive packets while the bandwidth hog is being a bandwidth hog, or at least soon enough after that the buffers are still full of hogswill. In which case, that next packet is surely quite likely to be from your interactive session after all.
Network experts: What am I missing here?
[Edited to add: My best guess is that what I'm missing is that "soon enough after that" may be quite a long time after. In any case, I don't see any way for what apenwarr wrote to be right.]
- phillijw 16y agoI believe he says that SQF+TBF is bad because SQF will first sort the packets before being sent to the TBF. This causes your high bandwidth applications to be less likely to drop packets because of the sorting and therefore cause your low bandwidth applications to drop more packets than you want. Without the sorting, you would have been more likely to drop the high bandwidth application packets because they come up more often. Again, they're not coming up "more often" anymore because they are sorted and sent in a round-robin fashion. I'm not sure why you couldn't just buffer them first and then sort them to solve this problem but I'm not a clever network engineer so I am certain I am missing a lot of knowledge here.
- akira2501 16y agoThe reason he had those problems, I'm guessing, is that he never setup traffic classing filters. Generally, I've never run _just_ TBF/HTB + SFQ. I've always run them hierarchically, HTB on the top interface, then several HTBs feeding into that one. Each of the lower HTB queues has a different amount of "flow" allowed to it. Once you approach it this way, it all works rather nicely. As the multiple queues allow you to spread bandwidth, but also priority into the higher level queue. I can run telnet/ssh sessions during a torrent swarm with no issues.