I’ve seen this request earlier but can’t find that post.
This already works in linux and useful mostly when adsl is used.
Let me explain my configuration (it’s standard):
Clients <=> RouterOS (PPPoE-client) <=> ADSL-modem (bridge) <=> DSLAM <=> Provider
Tariff upload: ~580kbps
DSLAM port upstream: 800 kbps
I’m not sure if I need to explain how adsl works and ATM cells are formed. But there is well-known problem with ACK-packets:
Let’s look at simple tcp ACK:
- 14 (ethernet) + 20 (IP) + 20 (TCP) = 54 bytes
-
- (6+2) (pppoe) = 62 bytes
Then we have to form ATM cells. Each cell can transfer 48 bytes of payload and moreover has own 5 bytes header. And as a result we get 53 bytes for each cell.
Since our ACK-packet size is at least 62 bytes we need 2 cells = 106 bytes.
Yes, ONE tcp ACK-packet (62 bytes) utilizes 106 bytes of our upstream bandwidth = (106 - 62) / 106 = ~40% wasted.
And worst of all that our RouterOS knows nothing about that, it sees only 62 bytes in queues calculations which are totally incorrect.
Some calculations using my configuration:
800 kbps = 102400 bytes/s can transfer (102400 / 106) = ~966 ACK-packets. If all our ACK-packets are 62 bytes then we can transfer (966 * 62) = 59892 bytes = 468 kbps. Not so bad.
But imagine our DSLAM port upstream is also 580 kbps instead of 800, what we get:
580 kbps = 74240 bytes/s → (74240 / 106) = ~700 ACK-packets per second. And (700 * 62) = 43400 bytes = ~340 kbps. This is our real upstream bandwidth in worst scenario. Awful.
And what values we should use in RouterOS’ HTB queues?
If we set 580kbit then ROS will send more packets than modem could send, our QOS will be useless.
If we set 340kbit then we lose ~50% of bandwidth.
Any suggestions?