Latency is the enemy of interactive audio and video. Packets that take too long to
get to their destination are as good as lost, and that lowers the quality of the audio
or video connection. Fortunately, you can tune your network to remove or reduce
latency.

You should aim to modify your transmission infrastructure so that during an audio or
video call there is never more than 400 milliseconds (ms) end-to-end latency, and less
than 100 ms jitter (a term used to denote variability in the delay). If end-to-end
delays reach or exceed these parameters, your callers will see artifacts on their
screens where data is missing or hear echo and pops in their audio.

Reducing network congestion is the key to managing latency on the LAN. One way to do
this is by increasing bandwidth, but that's not the only option. A number of Quality of
Service (QoS) schemes (such as packet prioritization using IP Precedence and DiffServ)
can help ensure that audio and video packets are handled with the highest priority
available. A single QoS mechanism implemented end to end should help lower latency on
the LAN.

For now, we'll focus on more traditional ways of efficiently using bandwidth to
address congestion. Most interactive video communications use 300 to 400 Kbps per
stream, while voice-only sessions use 30 to 40 Kbps. Since in a conversation the
streams are bidirectional, you would double those numbers to find the aggregate demand
on network resources for each conversation. Actually, you'd need to double those
numbers and add a bit more, thanks to the overhead imposed by packet headers. For
example, a bidirectional 384 Kbps videoconference consumes approximately 425 Kbps in
each direction.

To reduce congestion, make sure that you're using switched (not shared) 10- or
100-megabit Ethernet throughout the LAN. Your multimedia applications won't use all
this bandwidth constantly, but switched Ethernet is faster than shared Ethernet and
doesn't cost significantly more.

Make sure you employ nonblocking switches with output-buffered backplanes with a
capacity of at least 1 Gbps. That should help you avoid a kind of congestion known as
head-of-line blocking, which occurs when the traffic for the switch's ports
exceeds their line rates.

The most common way to lower latency on IP LANs where data, audio, and video
converge is to overprovision: you should provide enough bandwidth to meet the
highest possible load at all times. At nonpeak times, the high capacity is wasted.
Generally, this means buying more or faster switches; this approach is thus expensive,
though frequently still cost-effective.

Whether or not you overprovision, your choice of network topology affects packet
latency and the odds of packet collisions. Some network architects recommend that you
build parallel networks for data and realtime traffic (for voice and video). Under such
a design, you connect the data-only endpoints to one set of Ethernet switches, and
aggregate video endpoints on their own Gigabit Ethernet switches. This eliminates the
risk that video and data will battle for bandwidth. The two networks can still
communicate, to provide data connectivity when users want to collaborate on
applications, for example.

Other network engineers recommend mixing video and data-only endpoints on your
switches to reduce the possibility of having too many simultaneous video sessions
passing through and potentially overloading a single switch. The logic is that common
applications, such as Internet browsers and email clients, produce only
intermittent, "well-behaved" TCP/IP traffic that can mix with the continuous UDP
traffic generated by video applications. When the network becomes congested, switches
drop packets, and the data applications begin to resend them. As packet loss increases,
TCP/IP applications increase the interval between packets, reducing their relative
impact on UDP-based interactive video sessions in mixed networks.

The greatest risk involved in deploying endpoints this way is that, as traffic
congestion at the switch increases, mission-critical TCP/IP applications back off so
far that they time out and eventually terminate.

If your LAN already has abundant bandwidth, the "converged" network architecture is
easier to manage. If, on the other hand, you're already running at capacity and your
data applications are suffering from congestion, you need to consider what mix of
traffic runs on the LAN. Network-intensive applications, such as those that manipulate
large databases or graphics (for example, CAD/CAM drawings), use as much bandwidth as
video traffic and should not run on the same segments as realtime multimedia. Streaming
video servers are similar to two-way interactive video applications in that they use
UDP for transmission. They also don't back off when congestion arises because they do
not detect packet loss, so they tend to degrade interactive video application quality
if both occur on the same network segments.

Once you've conquered the LAN, you need to examine your options for wide area
traffic. For voice, your data network provider likely has services in place. For video,
watch for emerging WAN services over the next four to six months.