Kais Belgaied's Weblog at Sun

Dynamic Bandwidth Allocation

Now that we just released the Beta preview of the Crossbow project, and while the team is busy polishing the bits and send 'em to our Beta customers in a few weeks, I'd like to talk about one of the main features of this project, namely the ability to dynamically change the bandwidth allocation for a datalink or a flow. This feature may be used pro-actively to keep less time sensitive traffic from gobbling up all available bandwidth. Applications in general take as much resources as they can get out of the OS. They are rarely written with any resource sharing consideration. A periodic backup service for example is tuned to maximize its use of the network I/O, and won't exercise any discretionary self-pacing. Other more time sensitive applications, such as applications involving live interaction with humans,are at a disadvantage when they run at the same time as the backup service, and will result in a poor user experience.

If we know ahead of time the network usage profile of the most network intensive applications, we can create flows that describe the traffic they generate, and cap their bandwidth allocation to a level sufficient to let them run adequately, yet not high enough to starve the others.

Now, what if we don't know the amount of bandwidth that applications will use? What if there is an unexpected surge of traffic from one of the applications, or coming from a certain source or subnet and targeting multiple applications? A denial of service attack scenario for example. In this case, we need to protect the system resources by first detecting the surge, then by creating flows that represent the offending traffic, and finally dialing down the bandwidth allocation for those flows to a level that the system can handle. The steps above are essentially the containment measures of denial of service attacks.

The Crossbow observability features may be used for the detection step, as partially described in Venu Iyer's blog and the draft man pages. Future articles will cover it further.
This posting will touch on the other two step. The picture below is a screen capture of a demonstration we give at various occasions to illustrate the bandwidth regulation.

The setting for the demo is a machine installed with the Crossbow prototype, with one physical NIC, over which we have created a virtual NIC 'vnic2'
A remote machine shoots a continuous stream of TCP packets targeting destined to vnic2's IP address.
The picture shows two main window

• The control window running an interactive shell for issuing the commands (bottom right)


• A live graph that plots the bandwidth used by vnic2 every second (top left).
  (without animation, I'll have to count on the reader's imagination to visualize a continuously moving curve that actually draws a new plot on the graph)

In the beginning, we've got two flows defined over vnic2, one for TCP and one for UDP. The TCP flow is allowed the full 1Gbps available bandwidth, as shown by flowadm show-flow in the control window. The first twelve seconds on the graph show vnic2 under the continuous TCP attack. The bandwidth usage is at about 430Mbps, which is the maximum packets throughput that the single attacker could pump out. We then set the 'maxbw' flow property to 150Mpb on the 'tcp_vnic2' flow. Almost instantly, the bandwidth usage by 'vnic2' drops to about 150Mbs. We just protected the system from resources exhaustion caused by the attack on 'vnic2'. The protection selectively contained the actual offending traffic, which is the TCP flow, and did not "punish" other well behaving flows.

The scenario described in this article, is only a glimpse of what's now possible on the Crossbow preview Beta release, and soon with opensolaris. Many new new and enhanced features are also ready to be tested and deployed. In particular, a way to deploy Private virtual networks for Solaris xVM and Zones with Crossbow, that Nicolas Droux write about in his latest blog entry.

Posted by kais ( Feb 21 2008, 10:59:42 AM PST ) Permalink Comments [0]