Video Killed the Radio Star (Part 2 of 3)

In the first segment, we talked about several major trends that are increasing the amount of video traffic on corporate networks. In this second segment, we look at what you can do to start to get a handle on the impacts to your network.

Understanding Video Application Behavior

First, and foremost, the term "video" gets tossed around alot as an application, but in reality its a technology that enables or is included in many applications. Each video application has its own unique model of behavior and requirements on the network. So you need to understand the applications using video and understand their behavior. Some critical questions to ask include:

1. Where are the video sources and where are the viewers?
2. Which direction do the video flows traverse the network?
3. Is the video stored and viewed or real-time interactive?
4. How much bandwidth does the application require, static and burst?
5. What are the service level tolerances (latency, jitter, loss)?
6. What are the likely usage patterns in your company?
7. Are there requirements to connect to other companies (or customers)?
8. In what direction is the application likely to go in the future?

Lets look at a couple examples. First, lets look at Desktop Video Conferencing, which for our purposes here will mean using either a computer with a camera or a fixed videophone to conference with other people having similar endpoints. Our analysis might look something like:

1. Video sources: desktops, Viewers: desktops
2. Direction: desktop to desktop, or desktop to conferencing server
3. Real-time interactive
4. Bandwidth: 2 x 768kbps per call, bursting up to 1Mbps
5. Tolerances: latency<250ms jitter<20ms loss<0.5%
6. Usage patterns: adhoc meetings between any employee at HQ or branch offices
7. Other companies: not at this time
8. Future: likely shift to High-Def within 5 years

So that we can illustrate the importance of understanding the differences, lets look at one more example of IPTV, which will mean broadcasting of a stored or live video stream to many simultaneous viewers. Our analysis might look someting like:

1. Video sources: video storage servers or live feed, Viewers: desktops
2. Direction: storage to desktop, or live feed to desktop
3. Stored and viewed (but possibly also real-time for live feed)
4. Bandwidth: 1 x 512kbps per stream, bursting up to 512kbps
5. Tolerances: latency<250ms jitter<20ms loss<0.5%
6. Usage patterns: simultaneous viewing by many employees at HQ or branch offices
7. Other companies: not at this time
8. Future: integration with other apps

By this simple analysis we can understand quite alot. One of the important differences is where is the video orginating and where are the consumers. For destkop conferencing, obviously the sources and consumers are both the desktop. So the impacts to the network are very likely to be within the HQ Campus switching network, across the WAN, and to Branch Office networks. Provisioning may be a bit hard to predict as the likely usage will be fairly ad-hoc conferences. Voice calling patterns may lend insight into likely video calling patterns.

To contrast, the sources of IPTV streams are typically in the Data Center, from high-speed video storage servers. Because viewers can be essentially any employee, this will affect the HQ Campus switching network, WAN, Branch Offices, and possibly even remote workers over VPN. Since there will be many simultaneous viewers, it is inefficient to duplicate the video stream to each viewer, so wherever possible we would like to take advantage of broadcast optimization technologies like IP multicast and stream splitting.

Getting Your Arms Around the Apps

In this simplistic example, you can see why its important to understand how different video applications behave in order to understand how they are likely to impact your network.