Streaming video traffic from sites such as YouTube is flash-flooding bandwidth pipelines throughout the Internet. A recent report by deep packet inspection equipment provider Ellacoya suggests that P2P traffic is no longer the Internet's largest consumer of bandwidth. Instead, video-streaming formats that utilize the Internet as a transport mechanism have taken the top spot, accounting for 46% of all Internet traffic. In fact, streaming video represents 36% of all HTTP traffic. And of that 36%, YouTube represents 20% – equating to 10% of all traffic.
Why is this situation important to VARs and service providers? The simple fact is that the explosion of real-time bandwidth-intensive applications such as streaming video can put a substantial dent in the performance of your customer's key business applications. Estimates regarding YouTube's total daily bandwidth usage (through its content delivery partner, Limelight Networks) vary between 25 and 200 terabytes. The trick to delivering prerecorded video content is to rapidly transfer it to the client's machine and then have the client play it from a local hard drive, instead of directly from the site. Most video sites deliver files to the client faster than real time, so a two- to three-minute video is received in as little as 20 seconds, thereby giving the best local playback experience.
The problem with streaming video is not the file size (usually four to 10 megabytes, although it can be as much as 100 megabytes); rather, it's the rate of delivery. The content distribution network's sole purpose is to get that file down your customer's Internet connection to the client as quickly as possible, using as much bandwidth as possible. Even companies with substantial bandwidth can experience backups and clogged network traffic. No matter how much bandwidth your customer might have, the content distribution network on the other end has even more. Thus, every click on a YouTube video unleashes a tsunami of data that floods your customer's connection. These factors can pose a real problem for businesses that rely on Internet-based service providers for business-critical applications, such as payroll or CRM systems, and those businesses that host customer-facing services on their office's Internet connection. Service degradation and brief outages can occur if the connection becomes saturated with bursts of streaming HTTP traffic.
How can you control the streaming video traffic on your customer's network? There are a few solutions:
First, there's the "ostrich approach." You can leave your customer's Internet connection in its current First-In-First-Out, free-for-all state and hope that users do not decide to download the latest Diet Coke or Mentos video production.
Second, there is the "trying-to-kill-a-fly-with-a-sledgehammer approach." You can ban YouTube outright and block the site on your customer's Internet gateway. However, while the majority of YouTube content is for entertainment purposes, the site does have some educational and business-related information that could benefit your customers. At the very least, customers may find the site useful for seeing what others are saying in order to gauge public opinion of their company.
Finally, there is the "control-the-Internet-connection approach." You can control bandwidth allocations so that users can still access YouTube videos at reduced connection speeds while ensuring that those videos never interfere with business-priority Internet traffic. This solution is optimal, providing better control of the connection and allowing you to classify and apply policies to all Internet traffic – not just YouTube videos. The best part is, if you use a Cisco router as the Internet gateway, you already have this capability, and it requires no additional hardware. With a simple configuration, the Cisco IOS is able to identify and prioritize packets as they flow through.
For example, a Cisco router with a T1 connection to the Internet can be configured like this, assuming that Network Address Translation (NAT) is already configured if required. First, we match business-critical Web sites and protocols:
class-map match-any business-web
match protocol http url "*dimensiondata*"
match protocol http url "*salesforce*"
match protocol http url "*livemeeting*"
match protocol http url "*cisco*"
match protocol ipsec
match protocol dns
match protocol rtp
Then we match important, but not critical, Web sites:
class-map match-any other-web
match protocol http url "*oracle*"
Finally, we match the bandwidth hogs:
class-map match-any low-web
match protocol http url "*youtube*"
match protocol http url "*myspace*"
Then we create a policy map to apply treatments to the matched traffic. Business-critical gets 800 Kbps, important sites get 600 Kbps and low-priority sites get approximately 64 Kbps. All other traffic receives whatever bandwidth available but is also eligible to be dropped, though you can modify policies and bandwidth to suit specific requirements.
police cir 800000 pir 836000
police cir 500000 pir 600000
police cir 54000 pir 64000
Lastly, we apply the service policy to the inside (connected to your internal network) interface. This configuration is not supported on the outside interface, so the inside must be used. The bandwidth will be controlled by TCP windowing functions as we start dropping packets.
ip address 192.168.0.1 255.255.255.0
service-policy output internet-control
Using this method, you can specifically limit the amount of bandwidth available to YouTube or any other site. Also, the bandwidth allocation is not done by protocol, so other non-YouTube Web traffic is unaffected. The only thing to consider is the increase in router CPU utilization due to the extra effort required by packet inspection. As a side note, some video streams from YouTube are now coming from IP addresses from Google's blocks without a fully qualified domain name associated. Those streams would not be picked up by this configuration. If streaming HTTP video is really a problem, a more intelligent HTTP proxy should be used from companies like Cisco, Bluecoat or Packeteer.
About the author
Lawrence Imeish has been a member of Dimension Data's Converged Communications group for the past three years and was ranked the No. 1 solutions architect in the Converged Communications Practice in 2006. He has been involved in networking for nearly 15 years and also maintains a Cisco CCIE (#12000). Currently, Lawrence is the principal consultant for Dimension Data's Converged Communications Consulting Business Group (CBG). Working closely with enterprise organizations, he leads the CBG's efforts in assessing current technologies and aligning technology strategies with clients' unique business objectives.