ClusterFunk

Bandwidth Throttling

Towards the end of last year I conducted a proof of concept on a hardware TCP streaming appliance that has some very impressive stats for a 1u device. Non-disclosure prevents me from discuss the specifics however one of its key features is the ability to throttle bandwidth in response to the client requests, the appliance is aware of the encoding, container format and bit-rate of the asset and is therefore able to delivery just the right amount of data in the response to provide optimum user experience. This is in marked contrast to traditional http progressive download which starts sending as much data as it can (see below) resulting in periods of bursting activity or worse sending data that has already been cancelled by the user.

The ability to throttle enables a direct correlation between number of connections and bandwidth utilised/required. This is excellent news for solutions architects trying to design platforms capable of providing a consistent user experience based on number of users/clients. Here is an example of that correlation: 

Requests

Bandwidth

The stats taken from Hardware Appliance POC.

IIS 7 Bandwidth Throttling capability

“The Internet Information Services (IIS) Media Pack – Bit Rate Throttling module provides the ability to throttle progressive downloads of media files (in which audio/video playback starts as soon as sufficient data has been buffered on the client) based on the content bit rate. For sites that deliver audio and video files that may not be watched in their entirety, this module could significantly reduce your media-related bandwidth costs. A secondary feature of the Bit Rate Throttling Module is that it can also be used to throttle non-media ("Data") file types at specified bit rates”

Install

So lets install it then….

32 & 64 bit versions (Top top: its 64bit all the way now baby 32bit is so last century  )

http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1762

http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1764

That was painless

So IIS 7 can throttle the bandwidth of a given asset type based on configuration entered at the Server level, Site Level or directory level.

It is limited in the sense that it doesn’t inspect the media itself it relies on the media having the attributes as per the configuration (XML). 

If you wanted to host different H.264 container formats you would need to separate the assets into different server/site/directories. While I’m at it Silverlight is getting H.264 support which is good news for us TAs trying to deliver a one size fits all solution.   

No Bandwidth Control

Here is an example of none throttled asset playback. This image shows the playback of four sessions, notice the spiky nature of the trace. This is to do with the TCP/IP “congestion window updates” window. It is related to the way that the HTTP server fires off data while at the same time TCP/IP protocol utilises techniques to accommodate network events such as packet loss and network latency. The net result is burst traffic profile with some streams been badly effected.

Here is a single Asset

This is taken from my smooth POC setup. More details here.

Looking at the red line on the right you can see the asset starts playing at 300kbps and ramps up (v.quickly) to 2.436mbps. On the left is a capture of the nic output using task manager. Notice the initial burst of activity, this is an initial the population of a buffer cache, followed by the spiky data stream.

Bring forth the jiggery pokery (Turn on Throttling ) 

Now lets see the trace with a bandwidth throttle on the same asset. (Its difficult to see as the line is in line with the background grid) You can instantly see that the bandwidth delivered by the server is even and consistent.

It WORKS!

POC Appliance  

Its work mentioning that the hardware appliance mentioned at the start of this post does bandwidth throttling even better than IIS7 or equivalent Linux implementation for that matter.

Notice that unlike the trace above there is no initial burst. The asset starts streaming at a constant bit rate until it is completed.

What are the key benefits?

• Lower bandwidth costs by only sending required packets
• Deterministic behaviour per stream in relation to packet loss and round trip delays
• Higher aggregate throughput
• Traffic that is more suited to congested networks

and the most important in my view

• Each client / user gets the same quality of service in relation to data deliver assuming equal capability on the client side

Rather than re-invent the wheel there is a great article here about how to actually configure Bandwidth Throttling in IIS7 needless to say its pretty straightforward to set up and very cool

Also its worth mentioning that I am assured that this relatively strait forward to implement this using the “amazing” Zeus ZXTMs assuming you are not going to deploy IIS 7 e.g. you are delivering flash based media. I will have a word with the good people and Zeus to see if they can provide a knowledge base article around this on the substantial Zeus knowledge hub site.  

If you are interested in adopting this or any of the technologies mention on this blog please contact me via ioko – www.ioko.com and me or one of my fellow iokons (is that a word… no) will be more than happy to discuss your requirements.