Video can blow up your network, but with careful management and monitoring, it doesn't have to.

The issue of video's impact on enterprise IP networks has been growing in importance and has been drawing ever-increasing crowds at Enterprise Connect sessions. So I wasn't entirely surprised that, when we put the subject on the program at last week's Interop New York, the room was pretty full at 9 AM on Friday morning. Terry Slattery of Chesapeake Netcraftsmen consultancy, who does this session for EC in Orlando, presented the Interop session as well, and here's a rundown on a few of the points he made:

* You have to be pretty granular in your understanding of what traffic is really "undesirable". Terry started off with a quiz: Is Skype video acceptable or unacceptable in an enterprise network? What about YouTube traffic? The answer, of course is: It depends. You need to understand your enterprise's policies and practices--are users given permission to use Skype for business? Does the HR department host training videos on YouTube?

Once you understand what you're allowed to block, you can monitor for this traffic, but you still have to be on the alert--"You won't often be told of new video deployments, so look at the network, understand what's going on there," Terry suggested.

Furthermore, even when you identify undesirable traffic, you can't afford to take a broad-brush approach to blocking it.

Terry described a case study in which a company was receiving complaints about application performance across a T3 link. Volume increased on weekday mornings and fell off around the time workers left the office. Analysis found that the applications were TCP/HTTP-based, and half of the traffic was coming from just three sources: Pandora, Akamai, and LimeLight Networks. In other words, a lot of non-business-related traffic. Right?

To a degree, yes. But Terry pointed out that blocking those three sources could have caused real problems: Akamai & LimeLight are content providers, but they don't just serve up nonessential entertainment content. In fact, Microsoft uses them to provide Windows software updates. So you can't just block them--you have to be more specific in blocking traffic types.

* Enterprises need to refine their buffering practices. Terry gave the example of a company that was experiencing dropped packets even after splitting traffic into two classes: Application for business-critical traffic, and Entertainment, for non-business-critical, which would get any leftover bandwidth that the Application queue didn't use.

But the enterprise wound up seeing two-thirds of its packet drops in the Application queue and just one-third in the Entertainment queue. What was going on? It turned out that the enterprise's buffers were the same size in both queues, so that the heavy Application traffic overwhelmed that queue's buffers, dropping packets, whereupon traffic switched over into the Entertainment queue. The solution was to increase the size of the buffers in the Application queue, which reduced drops here and used this bandwidth more efficiently.

One caveat that Terry gave: Don't make buffers too big, or TCP traffic will send retransmissions for packets that are still waiting in queue, since those packets won't have been acknowledged to the sending end during their retransmission window. This eats up bandwidth needlessly.

* Terry also offered up a case study of heavy bandwidth-usage impact on a wireless LAN deployment. Though the actual application in this instance was a data-based medical records app (not video), the application's behavior mimicked that of a big video download, Terry said. Hospital staff found that the app's 15MB patient data downloads slowed the WLAN to a crawl, with round-trip times ballooning from 10 milliseconds to 230 milliseconds--"That's like [the time it takes to go] around the earth and back," just to communicate with a datacenter in the same building, Terry said.

The incident was a reminder that wireless offers the unique challenge that, especially in older networks, the WLAN may back off to the lowest possible speed, and retransmissions may further slow the network down.

The solution was to rewrite the patient records application's download algorithm to transmit the big files incrementally, rather that in a single push.

The bottom line from Terry's session: Video can blow up your network, but with careful management and monitoring, it doesn't have to.