Network Concerns for Videoconferencing
The success of any videoconferencing depends on the "end-to-end" bandwidth available and the quality of service characteristics of all network components along the way. By "end-to-end" one includes the hardware and software of the sending device, all of the communications devices between that device and the building connection to the campus network, the campus network itself, all of the wide-area connections (when applicable) and all of the above components back to the receiving device.
The bandwidth needed for one videoconferencing stream typically ranges from 384 to 768 Kbps. Adding network overhead of about 20%, you are looking at 461 to 922 Kbps. If a videoconferencing device is sending one videoconferencing stream (actually one audio and one video stream) to and receiving videoconferencing streams from three other sources, the total bandwidth needed will be six times the amount needed for one stream.
Videoconferencing devices send out data at regular intervals and the receiving device expects to get the data at the same regular intervals. As the data passes through each network device from sender to receiver, a minimum amount of delay (or latency) is introduced. If there are a number of devices between sender and receiver, the latency increases. If the latency exceeds 150 milliseconds, there is a possibility that people may be speaking over one another. Also, the latency for the audio stream may differ from the video stream which means that the sound coming from a person's voice won't match what his/her lips are doing.
Another potential problem is packet loss, which is typically due to a communications device that has become congested with too much network traffic. Under this condition, the communications device starts dropping packets, either equally among competing networked devices or in a prioritized manner if quality of service capabilities have been enabled (see below).
Jitter, which is the variation in latency, can also ruin a videoconferencing session. This is typically caused by networked devices competing for the uplink connection on a communications device whether it is an Ethernet switch or a router to the campus or wide-area network. This situation can be mitigated at the Ethernet switch level by recognizing video and audio stream traffic on a port and marking the Ethernet frames with IEEE 802.1p prioritization at a high level. (Note: All of the switches in the network, and the router to which they connect, have to recognize and support 802.1p for Ethernet prioritization to work.) At the router level, it must be able to support either Differentiated Services (DiffServ) or Type of Service (ToS) quality of service (QoS) markings so they can prioritize the timing sensitive traffic. (Note: All of the routers between the sender and receiver must support one of these two QoS mechanisms to maximize the probability of having a successful videoconference.)
So, what does all this mean in terms of one's videoconferencing needs? First, one has to look at the amount of bandwidth needed. If one wishes to have a videoconference with more than one remote location, the amount of bandwidth needed will be multiples of the amount needed for one remote location. For example, if one wants a four-way videoconference (which requires a device called a multi-point control unit or MCU), one will need anywhere from 2.766 to 5.532 Mbps of end-to-end bandwidth available at all times during the videoconference. Ethernet switch uplinks will usually have that amount of available bandwidth, but if there are any share hubs in the mix, then all bets are off.
The UGA campus network has 1 Gbps uplinks per building and a 2 Gbps core, and EITS has not seen more than 30 Mbps coming from any building nor has the core network links carried more than 60-70 Mbps. The UGA campus Peachnet link is limited to 100 Mbps for Internet 1/Peachnet traffic (we tend to bump up against this limit reasonably often) and 200 Mbps for Internet 2 traffic (of which UGA is only utilizing 20-30 Mbps currently). EITS may be asking for additional Internet 1/Peachnet bandwidth if the packet shaping devices they manage can't handle it. If the remote location(s) are off-campus, they may have a much smaller pipe than the Athens campus does, so it may be difficult to determine how much bandwidth capacity is available for videoconferencing on their wide-area links.
Second, the QoS capabilities of all communications devices between sender and receiver need to be addressed. The Athens campus core routers are capable of supporting and recognizing both 802.1p and DiffServ and ToS markings, although they have not been configured as such. The Ethernet switches connecting building networks to the core also support 802.1p. An assessment of the QoS capabilities of communications devices within buildings and remote campus backbones needs to be undertaken to determine if videoconferencing will be successful. If the remote site is on the state Peachnet network, EITS will need to initiate a pilot project with Peachnet staff to enable QoS capabilities within the Peachnet network itself. If the remote site is on the commodity Internet, it is highly unlikely that there will be sufficient end-to-end bandwidth for the videoconference, and it will be impossible to provision identical QoS capabilities among all of the Internet service providers between the UGA network and the remote location.
Once all of these issues have been adequately addressed, however, one can feel fairly confident that everything possible has been done to make videoconferencing successful.