The Technologies
To begin, lets assume we have some Box that sits between an internet connection and some network, and that the purpose of the Box is to somehow affect the flow of traffic to and from the internet. The Box has two ports, one going to an internet router and another connected to a switch that services any number of networks within the "intranet". All traffic must flow through the Box in order to get from the internet to the intranet, or from the intranet to the internet. Hence, every data frame can potentially be affected by the Box.Normally, without any sort of bandwidth management enabled, data frames are passed through the Box as quickly as possible. Data frames come in from the Internet and are passed as quickly as possible to the port connected to the intranet, and vice versa. This is how your typical router or switch functions.
Now lets compare how some bandwidth management technologies running on the Box work.
Queuing Algorithms - CBQ and Fair Queuing
Normally, all data to be sent is put into whats called a "queue". Since the connection on one side of the Box may be faster than the connection on the other side, data frames may arrive on one side of the box faster than the other. You don't want the Box to throw away the data, so its put into a "queue" until it can be processed by the slower interface. The data in the queue is then processed sequentially on a first-come, first-serve basis. Typically, it is sent out as fast as the target medium allows, which facilitates the best possible throughput with the lowest possible latency.CBQ, the most popular of the techniques and the one used in most low-end bandwidth management products (YDI, Microtik, turboPIPE, etc,.) stands for "class based queuing". Its a fairly simple technique where data is categorized into user-defined "classes" and then the queues are maintained for each class. Data can then be sent out according to time schedules and prioritized by processing the queues at specific intervals and/or in order of priority. However, in order to "reorder" data frames according to specified priorities, data frames are forced into "class" queues (which means they must be delayed) and processed at specific intervals, sent in order of priority. The purpose of this is to assure that higher priority data frames will always be sent out before lower priority frames. Therefore, high priority data cannot be bottlenecked by anything with a lower priority.
The negatives of CBQ are that it introduces latencies (delays) into virtually all traffic that is being managed, and that it is mono-directional in that only outgoing traffic can be controlled. It is also not practical to have a very large number of classes (queues) due to excessive overhead and loss of precision, so controlling hundreds of streams (or hosts, as an ISP might want to) will not work well. CBQ processes the defined class queues in a round-robin fashion: thus, as the number of defined classes increases, the efficiencies of the management decrease.
CBQ works best in a corporate environment where the user has control of both ends of the link, and where there are a few identifiable types of traffic that need to be managed.
"Fair Queueing" is a similar technique that attempts to allocate bandwidth based on the usage by individual flows. It attempts to be a bit more intelligent in making choices, and it's based on relative allocations rather than priorities. The problem with fair queuing is that in the vast majority of cases it does not do what you want to do; you don't want "fairness" between flows, you want fairness between your users or customers. "Flows" are simply a property of a larger entity, as each entity can have any number of flows. Also, like CBQ, Fair Queuing works well in environments where there are a small number of users and a small number of definable flows. When you have 1000 defined "pipes" or "flows", for example, its not practical to manage the flows "fairly" between so many queues.
HTB, the latest "craze" in the linux camp, is "yet another" queuing technique with the same problems: it doesn't scale well and its still a queue-based model. HTB addresses some of the precision issues with queuing algorithms, but it is simply not a technique that you can count on for the long run to manage a large network.
WRED, Diffserv, Token Buckets and other Silliness
At the turn of the century, Cisco had a problem. Bandwidth management was becoming an important concept, and their hardware was wholly inadequate to do it. They had supplied the world with routers and switches with just enough CPU power to do routing; with little extra cycles available to do cpu-intensive bandwidth management. At the time, Cisco dominated the Internet,and in order to address the inadequacies of their hardware, they came up with a series of bad algorithms that could be used on cpu-starved systems to shape traffic in a primitive way. Much like in the days of Microsoft dominance, many other vendors copied these algorithms and they became de-facto standards, not because they were good algorithms, but because they didn't have any better ideas.TCP Window Shaping and TCP Window Pacing
Back in 1996, when Emerging Technologies was the only company in the world with a real Traffic Shaper, I ran into Packeteer at a trade show; they were a startup that had a new idea; using TCP pacing, or TCP Window Shaping to manage flows. It was a novel idea that I didn't think was necessary; our queue based techniques worked well and at the time, most people only had 56K of bandwidth, or maybe a T1 at most. So we weren't managing very big networks.In 2000 I wrote an analysis similar to this one, making the claim that TCP Pacing wasn't necessary and that our technology was more precise and more efficient. In 2002, when we incorporated Window Shaping into our technology, I took some heat. "You said it was no good, now you're doing it!", they'd say.
Well as you gain experience, you learn. While I didn't like the idea of using TCP Window Manipulation as the primary means of limiting bandwidth, we needed a way to limit flows on congested networks. Many networks had more users that they could accommodate at once, and when too many customers were active at once, router's would have latencies that were too high. To illustrate how backup occurs, it's important to understand how TCP works. When you're downloading a file or a web page element, servers will send 1 "window" of data at a time. Then it waits for an ack, telling it that the data has been received and the receiver is ready for more data. In the 1990s most PCs only used windows of 32K or so; while now they're using much larger windows. As an example, lets compare a window of 64K, which is lower than most modern systems use, to a "shaped" window of 8K. While the browser advertises a window of 64K to the server, the shaper will change the announcement to 8k, so the server will only forward 8K of data at a time. Take the case when you have 3 TCP sessions active in the following diagram.
Window shaping
The router can only forward 1 packet at a time; with 3 connections theres substantially more data to process than when shaping is active. When you have 1000s of active connections, the differences in the amount of data to process is dramatic.
With local connections, large windows are required to achieve acceptable throughput. But with Internet connections, larger windows just cause congestion; you may get the same throughput with a window of 12K as you do with 64K. So the extra data just causes congestion and latency in your network. The Traffic Shaper determines the correct "Pace" to maximize the traffic flow.
The result of all of this is that you can get more customers onto your network. The Window Shaping creates "fairness", because each connection is only using the bandwidth that it needs rather than using big bursts of data.
It's important not to confuse Window Pacing with Window Scaling. Many vendors using lesser technologies (such as those based on Linux) mention scaling, but TCP Window scaling is just a TCP option that allows you to expand the TCP window beyond 64K. At this point in time, everyone supports it.
ET/BWMGR V8 Technology
First of all, when we asked one or our competitor's salesman what they knew about the ET/BWMGR, they told us that it was "like any other public domain software you can download from the internet." Perhaps this is what they'd like you to think, but it is completely untrue. The ET/BWMGR does not have one line of public code; it is a completely custom product, owned 100% by ETinc and you cannot get it anywhere else. The fact that it runs on FreeBSD does not make it public domain, nor does it imply that the product is somehow inferior. We chose FreeBSD because it's somewhat popular, and second because it's very fast, and 3rd because the license allows us to build products that we can own.In 30 years we've learned a lot about Bandwidth Management, and our V8 product is a culmination of that experience. We've learned that managing VOLUME on your network reduces congestion, and congestion is the foremost cause of network problems. Imagine a highway that's bumper to bumper at rush hour vs a highway that is sparse at 4AM. It's much easier to get where you're going quickly when there's less traffic.
The first concept of our product is common sense. When you connect to the internet with a 56K modem, things are slower than when you are on a T1, and you don't lose packets. In this way, TC
But limiting the speed of traffic is not that only element of bandwidth management that needs consideration. When congestion occurs, it is desirable for the bandwidth management device to be able to make on-the-fly decisions about what traffic streams should be streamlined and which streams should be throttled further. Drops are avoided whenever possible, but when discards are necessary, the ET/BWMGR drops lowest priority traffic rather than critical data. Because the prioritization is a secondary process, the ET/BWMGR has a higher capacity in terms of the number of classes it can manage because there is a separation of "pure limitation" and prioritization. Basically, the ET/BWMGR gives you the best features of queue-based bandwidth management without the negatives, while supplying more capacity.
The ET/BWMGR utilizes TCP window manipulation to shorten windows; effectively "pacing" traffic without dropping or delaying packets. This "slows" the connections and reduces congestion in your network.
UDP and other traffic utilize delay queues to precisely control the bandwidth to any level required.
"Low Priority" traffic takes a back seat to important flows like video that rely on consistent bandwidth to offer a quality user experience.
"Guaranteeing" Bandwidth
Many vendors tell you that they can "guarantee" bandwidth, but there is no real way to do this with any efficiency on the INTERNET. You can guarantee access to the wire, but you cannot guarantee the throughput of any particular application because you have no way of controlling or predicting what the delays (or packet loss) characteristics of the internet wires between you and your destination. The best you can realistically do is "try" to give them a specific amount of traffic, and to not manipulate is under a certain level. The best way to "guarantee" bandwidth is to make sure you don't have congestion; because on an open highway with sparse traffic you can go as fast as you want to go.Tiering Services
Bandwidth management allows our customers to tier their services; the ability to offer any level of bandwidth with a high quality experience. Imagine your competitive advantage being able to offer more service levels than your competitors who simply "slow" traffic to random speeds like they do on 5G and cable networks.Disclaimer: Competitor's descriptions are general and may not accurately describe newer versions of software. Please check with them for specifics about their products.