Managing IP Video Streaming Bandwidth
26 May 2000
Principal Network Consultant
PictureTel IP Services
Page 1 of 12
Managing IP Video Streaming Bandwidth
Bandwidth is the first concern often voiced by IT professionals when faced with the prospect of
incorporating video into their IP networks. What will be the bandwidth impact on my network? Does my
backbone have sufficient bandwidth to support these new applications? What will be the effect on my
current mission-critical applications?
This paper details the type and amounts of bandwidth required to support streaming video. Ways of
monitoring and managing the bandwidth are discussed so an IT professional can determine how to best
deploy these technologies for the good of his or her company.
The paper is structured in five sections (we need to establish the “flow” of the document) – these
suggestions are built on the existing titles and could be bold section headings. John or Fiona should advise
on logical groupings of information here.
1. Comparing data and video traffic
2. How much bandwidth is required
3. What is IP Multicast and how does it work?
4. Network Configurations and Impact
5. Network Solutions and Plans
1. Comparing Data and Video Traffic
Most computer networking traffic is a result of one computer trying to move a fixed amount of data to
another computer over the intervening network. The requirements for this type of transfer are that all the
data be moved, that there be no errors in the data, and that it gets there as quickly as the network will allow.
Network protocols have developed that ensure the data is moved without error. When network congestion
occurs, these protocols slow down the transfer of data and re-send frames that were received with errors or
lost, until the transfer is complete.
Because computers want to move data as quickly as possible, data traffic is sent when ready, and therefore
is very bursty by nature. A typical utilization graph for a data network is shown in Error! Reference
source not found.. Peak utilization numbers can be high, but an average of this graph would yield a
relatively low value. It is often difficult to predict or manage data utilization because of its bursty nature.
Peak utilization can often be an order of magnitude or more above the average utilization level. Average
utilization numbers often do not reflect the true behavior of the network, because the strong peaks shown
below are averaged over time, and reduced in value. There may be sufficient delays to reduce productivity,
yet the average utilization numbers
indicate that the network is only 25%
Video and audio streams have very
different characteristics than data
streams. The amount of data to be
transferred is directly dependent on the
length (duration) of the audio or video
session. The data is sent at a fixed rate,
a rate sufficient to support the quality of
the audio and/or video image desired.
Audio and video data are required to get
to the far end in a timely and predictable
manner, so they can be ‘played’, and
create a continuous audio sound or
visual image. For these data streams, the
delay time through the network (network
delay or latency), and the variations in
Figure 1 - Data Network Utilization
Page 2 of 12
that delay time (network jitter) are the most important parameters. If some of the data is lost or becomes
corrupted along the way, the receiving application does the best it can without the lost data, and continues.
The corrupted or lost data is never resent by the source.
Figure 2 is a graph showing the bandwidth utilization of a StarCast 1.5 Mbps video stream. Although
bandwidth variation can be seen, the average bandwidth utilization is very constant, especially when
compare to the data graph shown in
Starlight Streaming Figure 1.
2,000 Figure 3 shows the bandwidth
consumption of a slower streaming
video signal. This graph captures the
bandwidth used by a RealPlayer,
receiving a live broadcast across a local
area network (LAN). Note that the
streaming signal looks bursty at first
when the client is requesting enough
data to fill up its play buffer. Once the
buffer is full, requests drop off nearly to
zero, and then they return to a fairly
200 fixed level as the data is played, and
0 more data is requested to keep the play
1:15:27 1:15:32 1:15:36 1:15:40 1:15:45 1:15:49 1:15:53 1:15:58 1:16:02 1:16:06 1:16:11
Time buffer filled. During most of the
streaming session, this signal can be
Figure 2 - MPEG Streaming Video 1.5 Mbps considered a constant bandwidth signal.
Mixing the Two Traffic Types
When data and video/audio streams are
sharing the same network
infrastructure, their divergent
requirements conflict. A router
forwarding a large file transfer and a
video stream may slow down both
streams because of queue congestion.
While this causes no great problem for
the file transfer, it creates havoc with
the video session.
If the network supporting both video
and data communications has
Figure 3 - Streaming Bandwidth, RealPlayer sufficient bandwidth, no conflict
occurs. One acceptable approach to
insuring clean video is to overbuild the network, i.e. provide more than enough bandwidth for both
applications to ensure there is no conflict for resources.
Where it is not cost effective to over configure the network, Quality of Service (QoS) support is required.
QoS provides a mechanism to give priority to video and audio traffic, thus insuring it arrives in a timely
manner and with minimal packet loss.
Streaming Video Characteristics
This paper considers the impact that streamed video has on a network. Unlike real time videoconferencing
where the participants expect to be able to interact conversationally, most streamed video is one-way.
Response channels, if available at all, are text or voice, not video. As a result, streaming traffic is easier to
manage. Delays in the traffic stream, as an example, can be overcome with a buffer at the receiving end to
compensate for packets that arrive late or out of order. Streaming rates can also be managed, most
Page 3 of 12
streaming engines list a nominal stream rate, e.g. 28kbps, 400 kbps or 1.5 Mbps, which approximates the
steady-state flow rate for the stream. A companion paper “xxxx name xxxxxx” reviews network
bandwidth issues from the perspective of videoconferencing.
(As in the VTC paper I moved this paragraph to the end and made it into its own section. This is good
information, but the previous section is trying to point out the difference in the basic behavior of a video
stream vs. a data stream, and so putting this information in the middle of that discussion is confusing. I
believe it belongs here, separate from the previous discussion. JRB 28-Sep-2K)
TCP/IP and UDP/IP
TCP and UDP are transport layer protocols that run on top of IP. TCP is designed to provide a reliable
transport, one that ensures data arrives in complete packages without errors. TCP includes retry
mechanisms, and congestion management. UDP is designed to provide a lightweight datagram protocol for
applications that do not need or cannot use TCP. UDP traffic is packaged into frames that will fit the
network MTU (maximum transfer unit) size, and sent into the network. If they are lost somewhere in
transfer, the data is dropped, and the receiving application does its best without that information.
Audio and video data streams use UDP, because UDP characteristics best match the requirements for real-
time delivery of audio and video information. Data transfer and videoconferencing control traffic use TCP
to ensure all the information is reliably transferred across the network.
RTP Transport Layer
Data Link &
LAN Technologies WAN Technologies Physical Layer
Ethernet, Token Ring, FDDI ATM, Serial Lines, Frame Relay
Figure 4 - IP Protocol Stack
Figure 4 is a diagram of the IP stack that includes the protocols mentioned above. Packets flow down
through this stack during transmission, and up through this stack on reception. The layering shows how the
protocols relate to each other. IP is the common thread that binds together the different data link layers
(WAN and LAN). Data transfers usually use the TCP transport, and then pass through IP. The streaming
technologies (video and audio) use the UDP protocol, and may also use the RTP protocol (see below),
which relies on UDP for its transport. These streams then pass through the IP layer as well.
RTP, RTCP and RTSP
RTP is an additional IETF protocol that is used with real-time audio and video streams. Protocols that use
RTP run over UDP. RTP adds an additional 12-byte header inside of the UDP packet, and before the real-
time data. The RTP header includes timestamps and sequence numbers, which are used to ensure packet
ordering and to ‘play’ the packets at the right time relative to when they were created.
RTCP is a control protocol that is used in conjunction with RTP. RTCP provides valuable information to
the sender and receiver of real-time streams on the quality of the network connection, and the real-time
reception characteristics experienced by the receiver during a session. RTCP is a very low bandwidth
protocol, and should not concern the network architect in terms of bandwidth consumption. (Because this
Page 4 of 12
is the same text as the VC paper, I’m not sure whether RTCP is relevant to streaming – technical question
to which I’m sure there is a simple answer)_ - Yes RTCP is relevant to streaming, I don't know if streamers
take advantage of it but it is available for any RTP based protocol to use.
RTSP is a control protocol used by streaming clients to communicate with the streaming server.
Commands such as start, stop, and where to start within a video clip are handled by RTSP. This protocol
also does not consume much bandwidth, and need not be considered in bandwidth calculations.
2. How Much Bandwidth Is Required?
There are two parts of the bandwidth question, how fast are the streams and how do they combine in my
network to load individual segments? First we will look at the bandwidth consumption of individual video
Both videoconferencing and streaming video systems allow some combination of the users and the system
administrator to choose how much bandwidth the streams will consume. Higher bandwidth streams
provide higher quality video; lower bandwidth streams have less impact on the network. Companies
considering implementing video on their networks need to observe the video quality provided at different
levels, and determine which quality levels will solve the business requirements they are trying to address.
Video quality is a subjective judgment, and must be made by the principle users of the equipment to ensure
it will address their needs.
Figure 5 charts the bandwidth consumption of eight types of video streams showing their measured
bandwidth (as measured on the LAN), their payload bandwidth and the overhead incurred by the IP
protocol as a percentage. As this chart shows, a broad range of speeds are possible in a videoconferencing
environment, ranging from NetMeeting or Real running over modem lines, to business quality
videoconferencing or MPEG streaming running across the LAN.
Measured BW Payload BW Protocol Overhead
Figure 5 - Video Bandwidth Consumption
Figure 5 also shows the comparison between the payload bandwidth (those bytes actually used to produce
the audio signal or video image), and the measured bandwidth. The measured bandwidth is the total
bandwidth consumed on the network, including the protocol and data link layer overhead bytes. This
measured bandwidth is the value that should be used when calculating the impact of these video streams on
Page 5 of 12
The line in Figure 5 shows the protocol overhead in percent. The overhead percent reflects the length of
the packets used, since a fixed 58 bytes are added to each payload segment to create a packet. The larger
bandwidth users tend to use larger packets, and so they incur lower overhead penalties.
Table 1 lists the information used in Figure 5. Note the relationship between packet size and overhead
In this table and in the chart, shouldn’t we be distinguishing between streaming and videoconferencing?
Not all readers are familiar enough with the topic to know, for example, than NetMeeting is VC. Also,
shouldn’t we have StarCast in here? It is (still) one of our products and is a good example of high
bandwidth Mpeg Streaming.
Table 1 - Video Packet Length, Bandwidth, and Overhead
Video Product Size Measured Packets/ Payload Overhead
Bandwidth sec Bandwidth Percent
Business Quality Videoconferencing 915 781,593 107 735,466 6.3%
NetMeeting Video LAN (videoconf) 779 478,312 77 445,156 7.4%
NetMeeting Video DSL (videoconf) 363 187,726 65 159,800 17.5%
NetMeeting Video 28K (videoconf) 288 10,497 5 8,529 23.1%
PictureTel StarCast (stream) 1343 1,667,262 155 1,600,224 4.2%
RealAudio Radio (stream) 681 165,118 30 152,025 8.6%
Media Player 80K (stream) 697 81,171 15 74,882 8.4%
Media Player 20K (stream) 476 27,600 7 24,469 12.8%
Real Video 28K (stream) 384 25,173 8 21,633 16.4%
There are two main types of streaming video broadcast, multicast and video-on-demand, each having
unique network implications. Let’s start by considering multicast
3. What is IP Multicast, and how does it work?
What is Multicast?
Multicast traffic is a limited form of broadcast traffic. Because broadcast traffic is designed to reach every
end node in the network, the network switches automatically forward broadcast traffic out every port
except the port on which it was received. This ensures the broadcast will reach every node in the network.
Multicast traffic, rather than being forwarded to all output ports is only forwarded to “switch” ports where a
receiver is actively listening for that specific multicast address.
Figure 6 is a network diagram, showing a hierarchy of routers, a streaming video server and desktop
systems. The systems colored red are interested in receiving the video stream. The IP Multicast protocol
allows each router to make an intelligent decision about which output ports should receive the multicast
stream. Network segments carrying the multicast stream are also shown in red.
Multicast traffic relies on the Internet Group Multicast Protocol (IGMP) to know when active listeners
exist, and on which ports they reside. Multicast traffic is forwarded to those ports, and the ports are
periodically checked to determine if the listener is still active. When a listener stops listening, traffic is no
longer forwarded to that port of the switch.
In this way, a single media stream can be directed to only those specific ports where it is needed; the rest of
the network is spared the expense of supporting this media stream. As listeners become active and inactive,
the network automatically reconfigures itself to ensure they get the stream when needed, but do not get the
stream once they no longer need it.
Note that a single company-wide 400 Kbps streaming event, properly multicast throughout the network,
will only consume 400 Kbps on each link of the network it traverses. This type of event has manageable
bandwidth consumption. Multicast is most useful for multimedia streams that are viewed by a large
Page 6 of 12
number of users, and that are viewed ‘live’, meaning that all viewers see the same media stream
simultaneously. This can be an actual live event, it can be a constant media stream such as the broadcasting
of a commercial television station, or it can be a scheduled media stream such as a training video that is
being shown at 9:00 AM and 2:00 PM for those parties that are interested in watching.
Desktop Desktop Desktop Desktop Desktop Desktop Desktop Desktop
Desktop Desktop Desktop Desktop
Figure 6 - Multicast Network Example
How IP Multicast works
This section provides a brief explanation of how IP Multicast discovers which endpoints want to receive
the video stream, and how that information is communicated through the switch and router hierarchy.
Each multicast stream in the network uses a unique multicast IP address. Multicast addresses are in the
range 188.8.131.52 to 184.108.40.206. This address is used as the destination IP address for each packet sent
as a part of the video stream. This address is chosen by the system administrator, or assigned by a dynamic
process. Each endpoint learns this destination IP address through a web link or URL when the user selects
the video stream he would like to receive.
Identifying the Endpoints
Each endpoint that wishes to receive an IP multicast stream runs the IGMP Protocol. This protocol is
implemented by the IP software on each desktop. Microsoft based PCs need to be running Winsock 2.2 or
later to be able to receive a multicast stream.
The IGMP protocol broadcasts a request for the particular IP multicast address of interest. This IGMP
request is received by the router on the users segment. The router makes a note of which port the request
was received on, and marks that port as one requiring forwarding for that specific multicast IP address.
Note that the router can support many different IP multicast addresses simultaneously, with different
forwarding tables for each one.
The video server identifies itself to its router with a special IGMP command that indicates it is the source of
a particular IP multicast address stream.
Inter Router Communications
The routers communicate with each other using a different protocol, called PIM (Protocol Independent
Multicast.) PIM allows the router receiving the stream to connect with all routers who have clients wishing
to receive the stream. The routers build a distribution tree between them so that only those routers that
need to forward the stream will receive it.
Page 7 of 12
More information on IGMP and PIM can be found by using the references and links at the end of this
4. Network Configurations and Impact
In this section we will look at network configurations, determine where in the network bandwidth is used
and in what quantities. Here it is important to introduce the second main type of streaming, Video on
Two Types of Streaming
Streaming refers to an application that generates a constant stream of data to send either audio or video
information across the IP network. These streams can be delivered using the multicast mechanism
described above, where one source is split as many times as necessary by the network to reach all interested
receivers. Alternatively, the stream can be in the form of a Video on Demand, where it is carried point to
point from the source to a receiver wishing to receive it.
Streaming traffic is generated by two different types of application, and it is important to understand which
type of traffic is anticipated in the network to determine its impact.
‘Live’ streaming events are events that are either occurring at the same time that they are being viewed, or
are being sourced from a single source (such as a single video tape.) Examples of live events are the
broadcasting of the company president doing a quarterly address to the employees, or the re-broadcasting
of a commercial television station over the network. The key feature of this type of streaming is that the
event proceeds whether you are watching it or not. Just like the over-the-air TV broadcast, if you join the
session 1/2 hour late, you miss the first half hour of content.
The second type of streaming product is Video-on-Demand, analogous to a movie rented from the local
video store. With this product the client determines what video content he/she would like to view, makes
that request through a web interface to the server, and then views the content. This content could be a
training film, an advertisement clip, or a recorded copy of a live event. The key difference between this
type of event and the 'live' event is that each active user may be watching different video content
Clearly in this second case, the network is required to support as many video streams as there are active
users, with each stream being different. Even if two users are interested in the same training video, they
start them at slightly different times, and hence are watching different content and using different streams.
In the ‘live’ case, however, more than one user is watching the same video content. By using IP multicast
for this type of video streaming the same video stream is delivered to multiple destinations and the stream
only consumes the bandwidth on the network once.
Multicast Bandwidth Advantage
Let’s look again at Figure 6 to understand this bandwidth advantage. Each of the red clients wishes to
receive a video stream, and the video server (upper left) is required to supply them. If each client were
demand a separate training video, and the video streaming rate was set to 300Kbps, the server is required to
send 300Kbps X 3 users = 900Kbps of streaming data into the network.
However, if all three clients are instead watching the same live event, the streaming server can send out one
300Kbps stream using IP multicast. This single stream is replicated on two ports by the first router,
sending it both down the router hierarchy to the near user, as well as up the hierarchy to reach the other two
users. Following the path up the hierarchy, the next two routers (the top router and the next one down on
the right) are only required to forward the stream to the appropriate output port. The last router again
replicates the stream on two output ports to support the two requesting clients on the right.
In the Video-on-Demand scenario the server is required to source 900Kbps, as is its connection to the first
router. The top-level router is required to handle two streams (600Kbps) to support the two clients on the
right. In contrast, when using multicast, no segment in the network need support more than the 300Kbps
stream rate of the source, since replication is done by the routers, and only occurs at the last possible
location in the network.
Page 8 of 12
Table 2 shows a simple spreadsheet that calculates the required bandwidth for each scenario. This type of
calculation should be done before implementing streaming video, to ensure that the network can support
the expected traffic load.
Table 2 - Streaming Bandwidth Calculation
Simultaneous Sessions 3 sessions
Session Bandwidth (Kbps) 300 Kbps
Average number of receivers 20 receivers
Real-Time Video/Audio Sessions
Server sends (sessions * bandwidth) 900 Kbps
Client receives (bandwidth) 300 Kbps
Server sends (sessions * bandwidth * receivers) 18,000 Kbps
Client receives (bandwidth) 300 Kbps
Enabling Multicast on your Network
IP multicast functionality may not be operational on your network if no one has previously installed an
application that requires it. The routers in the network must have multicast turned on and configured
correctly before multicast traffic will be properly distributed. Talk to your network administrator to
determine if multicast is enabled. A white paper written by Cisco is referenced at the end of this document.
Switches vs. Routers
Local area networks (LANs) are often built using Ethernet switches. These devices may or may not
implement the full PIM protocol that allows them to participate with the routers in building the multicast
tree. If they are not true routers, it is still possible to have them participate intelligently in the multicast tree
if they implement CGMP (Cisco proprietary), or IGMP snooping. When these features are enabled, the
Ethernet switches monitor the IGMP packets being produced by the clients to determine which physical
segments have end-stations wishing to receive an IP Multicast stream. Although the switches are not active
participants in the IGMP or the PIM protocols, they still are able to determine which segments should be
included and which should be excluded from the multicast. This feature eliminates multicast traffic on
network segments where it is not needed, further reducing the impact of a multicast stream on the network.
Ensure Pruning is Operational
To determine if multicast is working properly in your network, connect a packet-capture device or
bandwidth monitor to a segment where no multicast traffic is expected. Start the multicast stream, and then
determine if the multicast traffic is on the quiet segment. A packet-capture device can look directly for
packets with the multicast IP address as the destination address. If a bandwidth monitor is being used,
determine if the bandwidth increases by an amount equal to the multicast stream when the stream is started.
If the segment under test does not have an active client looking for the multicast stream, it should not
receive traffic from that multicast stream. If multicast traffic is observed, either the routers or switches are
not properly configured for IP multicast.
Streaming over the Public Internet - ISP/NSP/Internet Issues
The general use Internet does not support multicast traffic today. Most ISP networks also do not support
multicast traffic. If your organization has a partnership with an ISP or NSP to carry your traffic between
sites, it may be possible to get multicast support, but it will need to be negotiated as part of the service
Streaming traffic that is received from the network, such as RealAudio radio stations or video clips from
the CNN website, are not multicast. The latter example is a video-on-demand application, and we do not
Page 9 of 12
expect it to be multicast because of the play-on-demand nature of this application. The radio station,
however, would lend itself to multicast. Since the Internet does not support multicast, each user within an
enterprise listening to the same Internet radio station will set up a stream from the source through the
Internet and through the corporate LAN. Many IT managers block these signals due to the amount of the
Internet access link consumed by these streams.
If receiving these streams is important to the business, the IT manager should consider re-broadcasting the
signal inside the enterprise, where multicast can be used. In this way a single stream could cross the
Internet access link and then be re-sent within the enterprise using IP multicast to support as many users as
necessary within the organization.
5. Network Solutions and Plans
When do I need to upgrade?
Bandwidth issues usually occur on specific identifiable links in the network, such as the backbone, the
client segment, or the WAN link. Issues arise on the client link if there are too many clients sharing an
Ethernet segment (a hub), or if a big bandwidth application is using the link. The second case would be
true for the streaming server. The simple solution to this problem is to isolate the server to its own switch
port, and to upgrade that port to 100Mbps or higher as necessary.
Backbone bandwidth congestion occurs from the aggregate usage of all system users, during the busy hours
of the day. The backbone bandwidth should be monitored on an ongoing basis so that the network
administrator can determine when backbone upgrades are necessary, and attend to them in a timely manner.
The WAN link is often bandwidth limited due to the lower speeds of most WAN connections. If streaming
video will be crossing the WAN links, careful planning must be done to ensure that there is sufficient
bandwidth on those links for the intended load, or to ensure that the load is managed to keep it within the
constraints of the link.
Bandwidth should be planned for the busiest hour or hours of the day. An estimate of the total traffic
through the segments in question at that hour should be made. Where possible, measure existing traffic.
Use these measurements as the baseline, and then add the expected video traffic on top of those numbers.
How much is too much?
Local area networks run well when their total utilization remains below 65%. Ethernet in particular does
not run well above that value due to the behavior of the CSMA/CD protocol it uses. Full duplex links
eliminate much of the CSMA/CD overhead, and can be run at higher utilizations.
Streaming data runs on the UDP protocol, which does not recover lost packets. Packet loss causes video
degradation, as outlined earlier in this document. As utilization numbers approach 100%, packet loss rises
exponentially. To run streaming video in your network without packet loss greater than 1%, the expected
utilization should remain below 65%.
Quality of Service (QoS) is a mechanism that allows some traffic to have higher priority than other traffic
on the network. Implementing QoS allows links to be more heavily utilized and maintains a low packet
loss ratio for the prioritized traffic streams. QoS is beyond the scope of this document, however the reader
is encouraged to explore QoS topics if high utilization is required in the network for economic or other
Local area networks (LANs) can be upgraded more easily than WAN connections. Migration from 10
Mbps shared Ethernet to switched Ethernet means replacing hubs, but does not impact the building-wiring
infrastructure. Consider moving to 100Mbps Ethernet, the incremental cost over 10Mbps Ethernet is not
If servers or clients have dedicated connections to the switch, those connections can be run full duplex.
This means that the bandwidth rating of the link is available in both directions simultaneously. 100 Mbps
full duplex link supports 100 Mbps transmit and receive concurrently.
Page 10 of 12
Network backbones can be migrated to Gigabit Ethernet, or ATM. New Gigabit Ethernet switches provide
a familiar environment to Ethernet users, and provide significantly higher bandwidth. ATM backbones are
useful for a big campus or where the backbone extends across leased fiber to remote facilities. ATM can
support other types of traffic along side the data traffic, such as voice or H.321 video. Sharing a common
infrastructure for all communications needs often brings economic advantages.
Upgrading the WAN links is more difficult because of their expense. Upgrading WAN links can be
justified if the business requires video streaming functionality. DSL (define on first appearance) lines are
available in many areas that can provide increased bandwidth at substantially lower cost than traditional T1
lines, and should be investigated.
A new alternative now being offered by network providers is a Virtual Private Network (VPN). VPNs are
a way of keeping a specific customer’s traffic separate, while carrying it on a public network. VPNs can be
implemented with ATM virtual channels, with MultiProtocol Label Switching (MPLS) or with encryption.
When considering a vendor providing a VPN solution, create a Service Level Agreement (SLA) that
specifically calls out the bandwidth requirements you expect during the busy period, and the packet loss
requirements you have for video quality (< 1%).
Video Bandwidth Management
The section above ensures the network can support the required amount of video traffic. The other half of
the bandwidth problem is to ensure that no more than acceptable levels of traffic are generated.
Multicast streams are managed by an administrator who can determine the number of multicast streams that
can be concurrently active, and can assign a bandwidth to each of them. This limits the amount of
multicast traffic that can be introduced to the network.
Video-on-demand systems also have bandwidth management controls. The bandwidth of a VoD session
can be specified by the administrator as a not-to-exceed value. Often VoD systems allow the user to
choose a number of quality/bandwidth levels, determined by how that user is connected to the network. A
dial-in user, for example, would choose a low bandwidth setting, while a LAN-attached user would choose
a higher quality. The administrator can determine that even the LAN attached user will never see more
than 300Kbps, for example. Additionally the administrator can determine how many simultaneous users
are allowed to be using the VoD system. This will again limit the total bandwidth introduced into the
Bandwidth is a major concern of the networking professional, when considering the installation of
streaming video. Streaming video can consume considerable amounts of bandwidth in the network. The
good news is that video bandwidth consumption is predictable, and manageable. Proper preparation and
management of usage can lead to a successful implementation, and satisfied users receiving high quality
video images over the IP network.
Multicast White Paper
A white paper on IP Multicast deployment written by Cisco can be found at:
Link to the IP Multicast initiative:
" streamingmedia.com - home of the streaming media industry and the world's leading destination for
businesses creating and distributing broadband/streaming content on the web."
A detailed technical paper on streaming video written by Cisco can be found here:
Page 11 of 12
PictureTel IP Services
PictureTel provides a range of services available to aid enterprise and network providers in determining if
their networks can support video, and how to upgrade them when necessary. More information can be
Page 12 of 12