Table of Contents

   Editor's Note
   Upcoming Events
   Quick Hits
   News and Announcements
   Guru's Corner
   Guest Editorial: Multi-Media Collaboration: Planning for Bandwidth

Even with all of the dark fiber out there, bandwidth always seems to be an issue. As more and more vendors deal with the convergence occurring in the RTC space (audio, video, and data conferencing), the bandwidth issue becomes more pressing. With a push towards security, and QoS that is necessary for VoIP bandwidth, or reserved bandwidth, is even more of an issue. But there is hope. Some vendors have taken the issue of bandwidth into account as they have built or extended their real-time multi-media applications. … David Coleman

A November 2002 article in the San Francisco Chronicle provides another interesting perspective on telecommuting. [1] According to the article, 25% of IBM's 320,000 workers worldwide telecommute out of home offices, saving IBM more than $700 million a year in real estate costs . As more organizations plan for and then implement multi-media collaboration within their population, their IT organizations typically spend time analyzing the intended application itself with respect to features and functions. Often times, there is no corresponding analysis performed with respect to the bandwidth requirements of such an application.

Audio Conferencing and VoIP

With “convergence” occurring in the real-time space more and more companies are offering audio (VOIP). The most recent issue of Time Magazine [2] proclaims “VoIP as the next big thing. By 2005 1 Gartner Group estimates that VoIP traffic will rise to 500 billion minutes. More than one half of large enterprise organizations have deployed or will deploy VoIP in the next 12 months, and nearly half of small and medium organizations will do the same. However, many of these organizations should be rightfully concerned about its scarce broadband resources. All software suites offering full multi-media collaboration utilize some compression algorithms and a CODEC for both audio and video. Very few applications are designed however, to work for the client to maximize that broadband resource.

Quality is one of the major issues in VoIP today. The key to sending voice over any network is compression as it reduces the raw bandwidth required to support the transfer. Briefly stated, in VoIP the voice content is compressed inside a packet along with a header for multiplexing, error control, and identification of the application by port number. It is usually run via real-time transport protocol (RTP) for payload identification, packet sequence numbering, time stamping, and delivery monitoring. On the receiving end, the process is reversed. However, these packets are often not delivered by the network at the same pace they entered it and some packets (usually at the beginning or end of the stream) can be lost in transit, creating “choppy” audio. VoIP often makes use of various techniques for echo cancellation, as echo becomes perceptible when delay exceeds 15ms-20ms, but these techniques still do not solve all the problems with quality.

CS makes two distinctions in VoIP that we believe are important. The first is that voice over a LAN or IP network that you have control over QoS (quality of service) is a different market than voice over the public Internet where you have no control over QoS. It is our belief that the first market will grow much more rapidly than the second just because there is are ways to reserve bandwidth for voice and insure a certain level of quality inside the enterprise.

To date, there is no way to insure Q0S over the public Internet, yet we believe that advances in compression algorithms will enable more of the voice packets to be switched over the public Internet without degradation. We believe that these algorithms will start to become commercially available in the next two years and that by 2005 we will see a large boost in VoIP minutes and revenues as some of our fellow analysts have predicted. The other side to this story, is that of the multi-media collaboration vendors reducing the size or amount of data that is sent over the Internet.

Using VIACK's VIA3 software as an example, we have seen a continual reduction in the requirements for high quality full duplex audio. Currently, the cost or “toll” you pay for this quality audio will “cost” only 12K per packet for both high and low bandwidth connections using VIA3. This has been reduced from a high of 64K over the past year. The benefit to the software manufacturer in terms of efficiency is almost nothing, but the benefit to the client in this instance is tremendous, and results in most e-meetings having a highly successful audio component.

Is A Picture Worth 1000 Words?

Video conferencing has been the “next big thing” on the collaboration technology horizon literally for decades, yet where we are seeing growth is the inclusion of video conferencing as part of a suite of real-time collaboration services. However, video conferencing still tends to be relatively expensive, fraught with technical limitations and, in too many cases, ultimately delivers a disappointing end user experience (“choppy” audio/video, dropped connections, etc.). As suggested above, if VoIP alone is having a difficult time making inroads into general business environment, how much more constrained is the adoption of bandwidth intensive video in those same environments? In CS estimation, video conferencing has only managed about 10% market penetration to date. Granted, they are very different technologies, but consider how much faster IM (instant messaging) passed that same mark.

As we touched on earlier, one can make a strong case that video conferencing, as we know it, will disappear in the next ten years as a uniquely identifiable market. As we have shown, the line between video and data/Web conferencing is disappearing rapidly already. CS believes video will be largely subsumed into the audio and PC world. There will always be some hardware sold, but video conferencing will become another access approach into the spectrum of RTC. However, most video is still ISDN-oriented today, so video will be subsumed into the IP world as this shift away from ISND occurs, over the next 5 years.

With video conferencing the bandwidth considerations are even more serious, with a 680x480 2.5”X2.5” sized live video window costing about 260K even with present-day efficiencies applied. Comparison between available applications offering real-time video reveals significant differences in the bandwidth cost per application. Again, using VIA3 as an example, VIACK has treated video as a bandwidth pariah and has re-designed its software to minimize video traffic (just sending pixel changes rather than the whole picture) itself as well as the amount of video data being sent by each e-meeting participant. VIACK is focused on “secure collaboration” and all media types are fully end-to-end encrypted. This makes bandwidth efficiencies extremely important as all video and audio data is being encrypted and decrypted at the desktop.

In this example, if a user has covered over their video window (most likely with another window), the application (VIA3) can recognize this and no longer receives video traffic to that desktop while the window is covered. VIA3 conduct this video analysis continuously for each meeting participant. Furthermore, when live video is being transmitted, VIA3 ships only those pixels that have changed from one packet to the next. With typical meeting camera settings less than 50% of a frame image has changed from frame to frame. By only sending what has changed, significant savings in reduced transmitted data can be achieved, with the result being less of a strain on the network or broadband connection.

 Every organization needs to determine for themselves their need for multi-media in their e-meeting strategy. Some organizations will elect to provide audio only because of the fear that available bandwidth will be severely compromised for many users throughout their organization if video is provided, and that video will only benefit few individuals, so that this bandwidth cost cannot be justified.

Sample Meeting Description

For all who realize that bandwidth analysis is a precursor to any successful multi-media implementation, here are some statistics to keep in mind based upon a somewhat typical full-featured meeting:

A meeting was held with four people using the VIA3 software, with audio and video being sent and received by everyone in the meeting continuously throughout the 38-minute test period. The participants took turns talking and did not generally talk over one another although that did happen occasionally as it would normally. There was moderate movement in each video window, with each person sitting during the majority of the meeting. The rate of data sent and received by one of the four computers during a 38- minute test period was measured and this system was established as the base line (BL) (see Figure 1).

 Observations

Most of the time, data (a mix of audio and video) was sent by the BL at a rate of 19.6 kilobytes per second (kBps), or 156.8 kilobits per second (kbps). The maximum rate at which data was sent out by BL was 44.3 kbps. In the chart below the 1% tolerance bars indicate the amount of bandwidth required to insure that 99% of the time, available bandwidth will not be exceeded in this sample meeting. The 1% is theoretical and is not related to a specific or stated acceptable level of quality. A minimum quality determination (i.e. maximum allowable dropout rates for A/V) may result in a higher tolerance percentage, thereby lowering the bandwidth requirements for this example.

The variances are great in this chart because the VIA3 software exercises efficiencies whenever necessary and will literally shut down virtually all packet transfer during brief periods of inactivity. Of course, the medium and mode are the numbers that reflect the most realistic bandwidth resource used for this example.

Figure 1- Audio and Video Conferencing Baseline

Many other factors can influence utilization efficiency, but none has a greater impact than the management of audio and video, particularly as the meeting membership grows bey ond 3-4 persons. Distribution of packets to all participants is geometric and can rapidly overwhelm most organizational resources

Breaking Up Is Hard To Do

Separating the two components of bandwidth for purposes of determining not only overall requirements, but the network capacity is a standard procedure for a multi-media bandwidth audit, which should always be done by IT prior to the use of any of these multi-media conferencing tools.

There are two parts to bandwidth audit that are required - upload and download.  The upload requirement is independent of the number of people in a meeting, since it reflects only that which is required to send a single computer's audio and video streams out to the other participants in that meeting.  The download bandwidth required is based on several factors: the number of people attending the meeting, the number of real-time video “on” connections (including efficiencies explained earlier), and the actual or programmatically chosen internet connection setting (i. e. ISDN, T1, 56K).

To use these charts below, perform the following analysis:

Step 1

Determine the actual packet size(s) for both audio and video, as specified by the collaboration software company (vendor). Audio should be fixed for all connection speeds, but if not, note the variances and for which connection. Video will be fixed for most manufacturers.

 Step 2

Check your upload and download Internet connection speed.  There are several web sites that you can visit, such as  http://den.speakeasy.net/ that can perform this check.

Step 3

Note your upload and download speeds and compare them with the charts below.

Example:

A person has a download speed of 566,825 bps , or 566 kbps .

This person's upload speed is 138,696 bps , or 138 kbps (about 1/4 the download speed)

Step 4

Evaluate upload and download speeds in conjunction with your software manufacturer's specifications.

Utilizing the audio and video packet sizes and variances of VIA3 we can make the following assumptions: With an upload speed of 138 kbps, I can only send my audio in meetings, not video, since 296 kbps is needed for both audio and video.

One person can receive video in a 3 person meeting (including that person), since the requirement is 510 kbps.  That same person cannot receive video in a 4-or-more person meeting since they would need 725kbps and only have 566kbps.  This person would have to stop receiving video from at least one of the attendees to be under the bandwidth available. In some software implementations, the video on one or more pictures will freeze, allowing the fourth video stream to be received. This is much like the time-sharing of a CPU in high-end computers, only here the resource being shared is bandwidth. This is not necessarily the optimum solution, as all motion in every one of the 4 windows will seem jerky or stilted and very unnatural. Often, these effects get blamed on the hardware (camera) or the software (vendor) and not on the real culprit, the limited bandwidth.

Figures 2 & 3 shown below represent bandwidth for a single non-shared connection. If multiple users share the same connection, simply multiply these values by the number of users sharing the connection.

Figure 2- Download Bandwidth Requirements

As mentioned earlier, in VIA3 all meeting functions (audio, video, IM, and data) are fully AES encrypted. The encryption is provided to every user to insure complete privacy and confidentiality from each desktop---end-t- end security. The effect on bandwidth to provide this high level of security is negligible. The amount of packet data transmitted over the Internet whether encrypted or non-encrypted is essentially the same.

 Summary

 Although the compression algorithms for all forms of multi-media conferencing are getting better, today there is no way to insure bandwidth (QoS) over the Internet. On a corporate network, IT has much more control over what goes over the network and can even reserve bandwidth for specific critical applications… such as multi-media collaboration. Given the fact that more and more RTC vendors are offering converged products (Audio, Video and Data), it is often up to the end user to determine if their broadband bandwidth is adequate to the task of multi-media collaboration.

There is some law (like Murphy's law) that say's that the amount of disk space on your hard drive, no matter how big will always get filled up. This same law seems to apply to bandwidth (in our observation) and whatever bandwidth you have, seems to get filled up. In the example above, ADSL (asymmetric DSL) was used, if you have symmetric DSL, i.e. the upload and download speeds are the same, then you would have less of a problem. In addition, the problem is being worked on from 3 sides, the vendors are trying to compress the amount of data sent over the connection, what is being sent is being compressed more and more effectively (i.e. the new Mpeg4 standard), and bandwidth providers are providing greater bandwidth at lower cost. Maybe one day all off that dark fiber we are told exists will get lit up and used? We believe that multi-media conferencing will be one of the driving factors for this.

Collaborative Strategies makes every effort to bring you timely, accurate information on collaboration and knowledge management. However, we are part of a rapidly evolving market ourselves and events occur during the publication of this newsletter every month that we do not become aware of or that happen post-production. If you know of such events please contact us at davidc@collaborate.com so we can note these key events in the next edition of this newsletter.