-
Notifications
You must be signed in to change notification settings - Fork 0
Evidence of the 80% 90% Principle
Claiming that the 80% / 90% principle is widely used, and that the correct sizing of the buffers of token buckets is not performed by most users without proof is not good. As a result, we collected a lot of evidence and related discussions on the Internet.
There seem to be no formal studies about this topic, thus most discussions are from forums, blogs, and wiki pages of related products and open-source projects.
In the tables below, "shaping" stands for the token bucket rate for outgoing (tx) traffic, and "policing" for incoming (rx) traffic. Note that the "police" here does not necessarily mean that incoming traffic are policed with the "tc filter ... police ..." command; it can also be redirected to a virtual device, e.g., imq or ifb, and then be shaped with htb.
Some of the discussions include both traffic shaping and policing paramters; some scripts have introduced more complex strategies setting the token rate, and they can not be represented by a single percentage.
We can find that most of the suggested percentage is between 80% and 90%, and suggested buffer sizes of the token bucket algorithm include:
- 128 packets
- 1000 packets
- 10240 packets
- max(49 ms, 6.25 KB)
- other (10 / 150 / 200 KB, 200 / 500 / 700 packets, 1000 ms)
A lot of discussions come from the forums of 3rd-party open source projects like DD-WRT, OpenWRT, and Tomato. We first use the internal search function in these forums to locate the posts with keywords like:
- QoS
- Quality of Service
- Bandwidth Control
- Speed Limit
- HTB
- VoIP
- BitTorrent
Then we did the same for discussions out of these forums with Google. The first 20 pages contain a lot of related discussions, but it then becomes quite difficult to find a related topic.
The search result from Google is not stable. As a result, the list may become quite different several years later. However, for such anecdotal evidence, it's the only way we can think of.
In the calculator application, we can see that the token bucket parameters depend only on the link bandwidth. This strategy is based on numerous simulation experiments based on ns-2 that we have performed.
However, in some of the related discussions, we have also found different approaches. For example, in http://bbs.dualwan.cn/viewthread.php?tid=20122, it is suggested that:
token_rate = bandwidth * (30 + online_hosts) / (20 + online_hosts * 8)
We cannot find support for this equation. It seems to be quite arbitrary but the basic idea is easy to understand: when there are more online hosts, the traffic load is heavier, so the token rate is lower. However, in the calculator application, the token bucket parameters only depend on the link bandwidth. Traffic load is not considered (actually it has been taken into consideration) and the equation has only one dependency.
We also noticed that a lot of users and router manufactures are against downstream traffic policing. An example is in the support page of Netgear routers:
In this page, we can only find options about tx traffic control (traffic shaping). For tx traffic, we have full control over the packets, and we can configure priority queues and fair queues to improve quality of service, which is relatively easy.
For rx traffic, we don't have direct control over the traffic, but traffic control is still possible. We believe that the negative options will disappear as related research and real-world testings continue.
| Target | Date | Shaping | Policing | Buffer Size | Path |
|---|---|---|---|---|---|
| Tomato 1.28 | June 28, 2010 | - | - | max(49ms, 6.25 KB) | /src/router/rc/qos.c |
| DD-WRT HTB rev 20939 | March 15, 2013 | - | - | sfq (128p) / codel (1000p) / fq_codel (10240p) | /src/router/iproute2/svqos.htb |
| DD-WRT HFSC rev 20939 | March 15, 2013 | - | - | sfq (128p) / codel (1000p) / fq_codel (10240p) | /src/router/iproute2/svqos.hfsc |
| OpenWRT 12.09 | April 25, 2013 | - | - | fq_codel (10240p) | /package/qos-scripts |
| WRT54 Script Generator 1.02 | 2007 | - | - | sfq (128p) / default (1000p) | - |
This is the most important category.
When users want to optimize their home networks, most of them will find that there's limited functionality available in factory firmwares, and then they begin to try open-source firmwares like DD-WRT, OpenWRT, Tomato, etc. The users who enjoy flashing routers and trying different open-source firmwares are only a small fraction of the entire user group, and they are often referred to as "geeks".
As a result, most of the discussions appear in a few technical blogs and forums that are not well known by most ordinary users.
Most "geeks" simply use the features provided in the web interface of different firmwares. That's why we consider it the most important. However, there seem to be a lot of inappropriate settings of the buffer size.
For example, in earlier version of DD-WRT, when the user enables downstream bandwidth limiting, and then added some priority classes (e.g., Premium, Express, Standard, or Bulk), an sfq is attached to each htb leaf class automatically. As each sfq has a buffer of 128 packets, the entire bufffer may be 512 packets or more.
In the "WRT54 Script Generator" known by many Linux router players, it's possible to create an htb leaf node for each user (identified by IP or MAC address). Users can either attach an sfq to each htb leaf, or just leave it alone. For a network with n users, the former choice leads to a total buffer of 128 * n packets, and for the latter, 1000 * n packets. Clearly, it does not make sense to configure so large a buffer. When different users start bulk transfers at the same time, the htb has to absorb too many packets before taking a drop, which leads to significant delay and jitter.
Similarly, for downstream traffic, the deployment of codel and fq_codel may lead to large jitter due to bursts of traffic.
The Tomato firmware police traffic in a smarter way. The buffer size of its setting is 49ms (with a lower bound of 6.25 KB), which grows linearly when the token rate increases. The basic idea that a higher rate needs a larger buffer is correct, but the equation needs to be verified.
| Title | Website | Shaping | Policing | Buffer Size |
|---|---|---|---|---|
| Quality of Service | www.dd-wrt.com | 80% - 95% | 80% - 95% | sfq (128p) |
| Peer-to-Peer (P2P) Throttling | www.dd-wrt.com | 80% - 95% | - | - |
| Using Tomato's QOS System | tomatousb.org | 85% | 66% - 80% | sfq (128p) |
| Configure QoS for VoIP on your router for better voice quality | www.voipmachanic.com | 90% | - | - |
| Implementing QoS | vonage.nmhoy.net | 90% - 95 | - | - |
| How to: Manage Traffic Using Tomato and QoS | www.wi-fiplanet.com | 90% | - | max(49ms, 6.25 KB) |
| Tomato QoS settings on your VoIP router | www.voipmechanic.com | 80% - 90% | - | - |
| QoS Setup | help.close.io | 80% | 80% | - |
| NetworkPro on Quality of Service | wiki.mikrotik.com | above 85% | above 85% | - |
| Setting up a maximum bandwidth (firewall/QoS) in a LANCOM router | www2.lancom.de | 80% | 80% | - |
| What is QoS and how do I use it? | help.fonality.com | below 80% | below 80% | - |
| DrayTek 2920 load balancing router | www.increasebroadbandspeed.co.uk | 80% | 80% | - |
| The Ultimate Traffic Conditioner: Low Latency, Fast Up & Downloads | lartc.org | 90% | 80% | 10 KB |
| Title | Website | Shaping | Policing | Buffer Size |
|---|---|---|---|---|
| The Beginner’s Guide to Using QoS (Quality of Service) on Your Router | www.howtogeek.com | 85% - 95% | 85% - 95% | - |
| Ensure a Fast Internet Connection When You Need It | lifehacker.com | 85% | 85% | sfq (128p) |
| The Basics: Configure Quality of Service (QoS) for VoIP | dailybeagle.com | 90% - 95% | 80% - 90% | max(49ms, 6.25 KB) |
| Quick and Easy QoS with Tomato | chillingsilence.wordpress.com | 94% | 90% | max(49ms, 6.25 KB) |
| How to Prioritize Your Network Traffic with DD-WRT | www.howtogeek.com | 80% - 95% | 80% - 100% | sfq (128p) |
| Hierarchical Fair Service Curve (HFSC) | calomel.org | 97% | - | 500p |
| Traffic Manager - QOS | rtn66u.blogspot.jp | 70% - 80% | 70% - 80% | - |
| Title | Website | Shaping | Policing | Buffer Size | Notes |
|---|---|---|---|---|---|
| qos-nxt | github.com | 80% | 80% | 500p | |
| Rob Brewer's Firewall and QoS Scripts for OpenWRT | www.robbrewer.me | 90% | - | 150 KB | |
| A script for QOS | www.dslreports.com | - | - | sfq (128p) | |
| Dedicated VOIP bandwidth - WRT54 Script Generator | www.dslreports.com | - | - | sfq (128p) | |
| QoS for OpenWrt | www.rooot.net | - | - | 200 KB | |
| An Interesting QOS script example | www.linksysinfo.org | 76% | 76% | default (1000p) | |
| QoS script for DD-WRT from Alex Rice's blog | pastbin.com | 85% - 90% | - | - | |
| 15.10. Example of a full nat solution with QoS | lartc.org | 80% | - | - | |
| QOS Script for OpenWRT | www.docunext.com | 81% | 95% | 10 KB | |
| 发一个双wan的智能QOS脚本（2010年6月17日更新附单wan） | bbs.dualwan.cn | - | 91% | sfq (128p) | (in Chinese) |
| 智能QOS脚本横空出世 | bbs.dualwan.cn | - | - | default (1000p) | (in Chinese, imq0 / class 1:255) |
| 对zhoutao0712 qosv2.0 脚本的增强 第四次更新 | bbs.dualwan.cn | - | - | sfq (128p) | (in Chinese) |
| 技术研究 QOS：周大师V4.0和cmt1978 等脚本的综合修改试用版0.1 | bbs.dualwan.cn | - | - | sfq (128p) | (in Chinese) |
| P2P惩罚 QOS脚本 V4.0 | bbs.dualwan.cn | - | - | sfq (128p) | (in Chinese) |
| 双wan极速飞驰版QOS脚本，v0.5 | bbs.dualwan.cn | - | - | sfq (128p) | (in Chinese) |
| 智能QOS脚本修改版 | bbs.dualwan.cn | - | - | sfq (128p) | (in Chinese) |
| 小包优先+WEB优先+IP限速+连接数限制 的脚本 | bbs.dualwan.cn | - | - | sfq (128p) | (in Chinese) |
| 儿童节发布K26支持任意网段限速QOS脚本，打得openwrt满地找牙 | bbs.dualwan.cn | - | - | sfq (128p) | (in Chinese) |
| 发布K26 QOS脚本，打压openwrt势力 | bbs.dualwan.cn | - | - | sfq (128p) | (in Chinese) |
| ADSL QOS脚本 V1.1 | bbs.dualwan.cn | - | - | sfq (128p) | (in Chinese) |
| 小包优先+web优先+游戏爆发+单IP限速+连接数限制 QOS脚本V2.0 | bbs.dualwan.cn | 78% | 88% | sfq (128p) | (in Chinese) |
| Title | Website | Shaping | Policing | Buffer Size | Page |
|---|---|---|---|---|---|
| Setting up a DrayTek 2830n for SYNETY VoIP QoS | www.synety.com | 80% | 80% | - | 2 |