Embed Size (px)
Citation preview
Page 1 of 12
Managing IP Video Streaming Bandwidth
26 May 2000 Version 1.3
John Bartlett
Principal Network Consultant
PictureTel IP Services
Page 2 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% utilized. 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
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 Figure 1. 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 fixed level as the data is played, and more data is requested to keep the play buffer filled. During most of the streaming session, this signal can be considered a constant bandwidth signal.
ia
WQm
STwRmc
Starlight Streaming
0
200
400
600
800
1,000
1,200
1,400
1,600
1,800
2,000
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
Kbp
s
s
Figure 2 - MPEG Streaming Video 1.5 MbpMixing 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 sufficient bandwidth, no conflict occurs. One acceptable approach to
r
Figure 3 - Streaming Bandwidth, RealPlayePage 3 of 12
nsuring clean video is to overbuild the network, i.e. provide more than enough bandwidth for both pplications to ensure there is no conflict for resources.
here it is not cost effective to over configure the network, Quality of Service (QoS) support is required. oS provides a mechanism to give priority to video and audio traffic, thus insuring it arrives in a timely anner and with minimal packet loss.
treaming Video Characteristics his paper considers the impact that streamed video has on a network. Unlike real time videoconferencing here the participants expect to be able to interact conversationally, most streamed video is one-way. esponse channels, if available at all, are text or voice, not video. As a result, streaming traffic is easier to anage. Delays in the traffic stream, as an example, can be overcome with a buffer at the receiving end to
ompensate for packets that arrive late or out of order. Streaming rates can also be managed, most
Page 4 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)
The Protocols
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.
LAN TechnologiesEthernet, Token Ring, FDDI
WAN TechnologiesATM, Serial Lines, Frame Relay
IPICMP IGMP
ARP
TCPUDP
RTP
Data Link &Physical Layer
Internet Layer
Transport Layer
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 5 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 streams. 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.
0
200,000
400,000
600,000
800,000
1,000,000
1,200,000
1,400,000
1,600,000
1,800,000
384K
Vide
ocon
fere
nce
Net
Mee
ting
Vide
o, L
AN
Net
Mee
ting
Vide
o, D
SL
Net
Mee
ting
Vide
o, 2
8K
Pict
ureT
elSt
arca
st
Rea
lAud
io R
adio
Med
iaPl
ayer
80K
Med
iaPl
ayer
20K
Rea
lVid
eo 2
8K
0.0%
5.0%
10.0%
15.0%
20.0%
25.0%
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 the network.
Page 6 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 percentage. 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 Bandwidth
Packets/ sec
Payload Bandwidth
Overhead 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 7 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
DesktopDesktop
Desktop
Video Streamer
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.
Multicast Address Each multicast stream in the network uses a unique multicast IP address. Multicast addresses are in the range 224.0.0.0 to 239.255.255.255. 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 8 of 12
More information on IGMP and PIM can be found by using the references and links at the end of this document.
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 Demand (VoD).
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 simultaneously. 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 9 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
ParametersSimultaneous Sessions 3 sessionsSession Bandwidth (Kbps) 300 KbpsAverage number of receivers 20 receivers
Real-Time Video/Audio SessionsServer sends (sessions * bandwidth) 900 KbpsClient receives (bandwidth) 300 Kbps
Video-on-demand SessionsServer sends (sessions * bandwidth * receivers) 18,000 KbpsClient 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 agreement. 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 10 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 reasons.
Upgrade Paths 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 too much. 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 11 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 network.
Conclusion 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.
References Multicast White Paper A white paper on IP Multicast deployment written by Cisco can be found at: http://www.cisco.com/warp/public/cc/cisco/mkt/ios/mcastip/tech/ipcas_dg.htm Link to the IP Multicast initiative: http://www.ipmulticast.com
Streaming Media " 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." http://www.streamingmedia.com/ A detailed technical paper on streaming video written by Cisco can be found here:
Page 12 of 12
http://www.cisco.com/univercd/cc/td/doc/cisintwk/idg4/nd2013.htm#18023
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 found here: http://support.picturetel.com/services/ipvideoservices.htm
