How does your network react to the increasing using of video? What are you doing to understand the sources of video so that you can prioritize them, relative to each other and to your business applications? When do you add network capacity to congested paths? I am hosting a session at Enterprise Connect 2012 titled How To Keep Video From Blowing Up Your Network, March 26, in which these and other questions will be covered.
To prepare for this session, I've researched a number of papers on the impact of video on the network. What I found were papers that primarily talked about video or P2P file sharing. These papers were surprisingly old--around 2004. They typically discussed the impact on the Internet, which wasn't really of interest with respect to the impact of video on an Enterprise network. The study of video in an Enterprise would be a good Masters Thesis or a good topic for a University researcher who needs a scholarly paper. (If you know of a paper on this topic, please let me know.)
Sources and Sizes of Video
There was one interesting fact from the collection of papers. The viewer typically selects the highest resolution video available. The size of the video transfer means that video data transfers significantly dominate data transfers of all other types (e.g., email, web browsing, music downloads, streaming music, etc). A music file may be 2-10MB in size while a full-length movie may be 500MB-4 GB in size. So one movie transfer has a lot more impact than a lot of people doing music streaming.
You can also expect a big impact on corporate networks whenever there are significant worldwide events, with streaming video feeds. Examples are the Michael Jackson funeral, the annual March Madness basketball games, or the World Cup Soccer matches.
Many of the larger enterprises are now using telepresence systems to reduce the need for travel and to provide a better means of collaboration between diverse team members. These systems use significant bandwidth when they are running--around 5Mbps per HD display.
Finally, there are the desktop video conferencing systems such as Skype that are used by smaller enterprises for collaboration. I frequently use Skype for collaboration with other Netcraftsmen team members when we're working on projects or need to discuss a topic or document. For example, I recently needed comments from a co-worker on a network design, and wound up spending over two hours in a video call in which I shared a document and my co-worker was on video. Our session probably didn't use a lot of bandwidth. The Skype documentation says that video calling and screen sharing uses about 128Kbps. But it is continuous, which raises the base traffic volume running on the network.
Video Transport
Video conferencing systems typically use UDP for their transport, and you can easily identify their streams by matching the protocol. However, other video sources use TCP, such as Netflix downloads and YouTube. Many of these are transporting the video over TCP port 80 (HTTP) or 443 (HTTPS), which makes their identification more challenging. Flow analysis (Netflow, sFlow, etc) can help identify these sources of video because of the flow volume.
The TCP-based transport is preferable over UDP because TCP will reduce its data rate when it senses packet loss. We used this to our advantage with a customer as described in a blog post at Netcraftsmen. We used QoS to force the entertainment traffic into a low-priority queue that was configured to consume any remaining bandwidth after the business application traffic had been handled. Our QoS classification identified traffic by source address, so we didn't have to try to identify the specific protocols. When QoS dropped packets in the video flows, TCP slowed its transmission rate.
A UDP stream would have made it part of the way across the network before it encountered the QoS policy that would have dropped packets. No flow control would have been possible, so the network bandwidth consumed by the dropped packets would have been wasted. However, the flow control induced by dropping TCP packets reduced the bandwidth of the streaming transfers, which helped reduce the bandwidth consumed all the way across the network. This was a big win.
Link Utilization Analysis
In the case of applying QoS, the link was a T3 (45Mbps), so it wasn't a slouchy link. But it was saturated during business hours. An analysis using the Opnet Application Response Xpert system showed that about 50% of the traffic was what we identified as entertainment traffic. It originated from Pandora.com, Akamai Networks, or LimeLight Networks. Pandora is an Internet streaming music site and its FAQ site says that it wants network connection of 150Kbps per listening session. With multiple people listening, it used some bandwidth. There were about 20 people at the remote site, so if everyone were listening to music, it would imply consumption of only 3Mbps. The Akamai and LimeLight sites are content providers and we determined that most of the network bandwidth was consumed with video downloads.
In this example, the video downloads had a big impact on the network and its ability to support the business applications. The people at the site were constantly complaining about the applications being slow. What they didn't realize was that they were hurting themselves with the downloads. After we applied QoS, they were satisfied with the business applications. There were a few comments about how the Internet was now a slower than before. ;-)
Other Sources of Video
There are more and more sources of video on Enterprise networks these days. Examples are Webcams (NannyCams or watching your pet at home), YouTube, Facetime, Netflix, Telepresence, Skype, personal video conferencing systems (Cisco/Tandberg Movi), and Webex. Determining which video applications have priority over other applications is going to be an interesting problem to solve.
Join me in Orlando at Enterprise Connect in March to learn more about handling video in Enterprise networks.
