In an age of unlimited bandwidth; how do we prevent a “greedy” user from consuming all of our bandwidth? “Bandwidth controllers” (BWC), a feature of BIG-IP, can help prevent an overflow of data and keep things fair.
Some examples of using BWC would be to limit the amount of data that can be downloaded from an AWS S3 bucket or prevent a user that is streaming a 4K video from saturating the network.
Bandwidth Controllers
On the BIG-IP we can control the amount of bandwidth that an application or user gets. This could control the amount of bandwidth that a user can get to access an application you provide (ingress) or the amount of bandwidth that you provide to the Internet (egress).
Bandwidth controllers can use either a static or dynamic policy to control bandwidth.
Static Policy
A static policy provides an aggregate bandwidth limit. Think of this like taking a garden hose and adding a nozzle. All requests are throttled evenly across the defined max. For example, you can limit a site that provides file downloads to 100 Mbps.
A static policy is very simple and can be useful to apply an egress policy like “students share 100 Mpbs of internet and faculty share 1 Gbps of internet based on the originating subnet” or limit backups/games that go over port XXXX to 100 Mpbs.
Dynamic Policy
A static policy can be abused. In the previous egress scenario a savvy student could create multiple connections and “steal” bandwidth from other students.
A dynamic policy provides a fairer mechanism to apply both a global (similar to static) and “user” policy. A dynamic policy could refine the previous example to impose a 10 Mbps end-user limit based on source IP address as well as the overall max of 100 Mbps for students and 1 Gbps for faculty.
To use a dynamic policy you need to define what is the key or bucket that you want to sort your users by. This could be an IP address, session ID, or other criteria.
In Action
The following is an example of limiting access to an AWS S3 bucket. It does the following:
- Limit overall download to 200 Mbps
- Identify users by either IP address or X-Forwarded-For header
- Limit individual user to 100 Mpbs
Policy
Here is an example of the dynamic policy that implements the 200 Mbps and 100 Mbps limits.
Identifying User
The method to identify a user can be done with the following iRule.
This iRule accepts either the client IP address or the X-Forwarded-For header. This could also key off a header that is sent by the server if you want to have a custom X-BWC-Policy header that is set by the application (i.e. authenticated users get 10 Mpbs of download and anonymous users 1 Mpbs).
Example Scenario
In this example you can see the first user gets the full 100 Mbps on their first connection (~12 MB/s).
When the first user opens a second connection the bandwidth gets split between the two connections (~6 MB/s each).
When a second user connects they also get the full 100 Mbps of bandwidth (~12 MB/s).
When a third user connects you can see the traffic gets split across the 3 users to keep the overall max under 200 Mbps (~8 MB/s per user).
Note that 100 Mbps is ~12 MB/s this is one of those fun there are 8 bits in a byte (100 megabytes / 8 = 12.5 megabits). Upper case B is bits and lowercase b is bytes.
Level Playing Field
A more sophisticated deployment could also make use of Service Provider features that can provide finer granularity. Please see, "PEM: Subscriber-Aware Policy and Why Every Large Network Needs One", for an example of using this feature to limit traffic based on URL classification.
Bandwidth controllers are useful to keep the peace and allocate resources fairly.
This helped us move past the original error and we are now seeing the following. It is almost as if because the traffic is coming from the same IP it is throwing an attachment error.
/jeff
Thanks Eric,
With the assistance of another colleague we've now been able to generate a config that works for all traffic so I thought I'd come back and post the settings used. I've had it confirmed that for traffic shaping when not using a 'standard' VS type you need to use 'Rate Shaping' and not 'Bandwidth Controllers', so that was the major thing. We used a 'Performance(L4)' VS type. The Protocol Profile was left as the default 'fastL4'. In the environment is was doing testing I needed Source Address Translation (AutoMap), in a real environment this shouldn't be required so long as the return traffic routes via the BIG-IP.
