Table Of Contents
Implementing TelePresence over Broadband
Quality-of-Service (QoS) Configuration
Implementing TelePresence over Broadband
Published: 10/20/09Contents
Overview
This document provides basic implementation guidelines for deploying a Cisco TelePresence System 500 [1] in the home office over high-speed broadband and a Cisco Virtual Office (CVO)[2] topology.
The business value of this deployment is characterized by:
•
Weather related travel restrictions—Employees may not be able to travel to the office due to winter storms or hurricanes and other severe weather issues.
•
Pandemic planning—Travel outside the home may be restricted due to influenza or other bio-hazards. It is estimated that one-third of the human population was infected in the pandemic of 1918/1919.[3].
•
Day extension—It is becoming increasingly common for job responsibilities to include co-workers spread over multiple time zones. A manager based in the United States may have direct reports in China or India. Cultural differences and language barriers make face-to-face communications more effective than E-mail or audio-only conferences.
•
Leveraging critical human resources—Employee effectiveness can be enhanced by minimizing travel while maintaining the personal touch the Cisco TelePresence provides.
As the costs of business class broadband decrease, and at the same time the available bandwidth increases, implementing a home office based on the Cisco TelePresence System is a viable extension to the existing corporate TelePresence systems already in use.
Components
The relevant components to this deployment include the following:
•
Cisco TelePresence System 500
•
Cisco Virtual Office router, a Cisco 881 Integrated Services Router (ISR) connected to headend aggregation VPN routers. DMVPN dual-hub, dual-cloud is used in internal Cisco deployments.
•
Business-class broadband, asymmetrical bandwidth, with a minimum of 2 Mbps uplink. Most service providers offer downlink 4 to 5 times the provisioned uplink bandwidth.
Network Topology
This section discusses the WAN network topology and specifics of the home network topology used in testing and verification.
WAN Network Topology
Testing of this solution within Cisco has been conducted in both San Jose, CA and Research Triangle Park (RTP), NC.The WAN network topology in the RTP location is shown in Figure 1.
Figure 1 WAN Network Topology
The WAN topology is a DMVPN overlay of the corporate IT network. The DMVPN deployment is a dual-hub, dual-DMVPN cloud using Enhanced IGRP (EIGRP) as the routing protocol inside the tunnel interfaces. The DMVPN deployment is managed by Enterprise Solutions Engineering (ESE) while the underlying network topology and Internet connectivity is managed by Cisco corporate IT. Internet connectivity is provided through three, tier 1 ISPs, using Packet-over-SONET burstable to the port speed of OC-12. The goal is to increase Internet bandwidth to support all forms of Cisco Virtual Office to 4 Gbps bursting to 10 Gbps. Additionally, direct connectivity to the ISP/Broadband provider servicing a majority of the Teleworkers is planned.
For planning purposes, Internet bandwidth requirements at the campus headend location is 2Mbps in each direction, per remote-user, on an active call. Each deployment must estimate and during deployment measure, the number of concurrent Telepresence sessions and provision accordingly.
While downstream QoS can be enabled on the DMVPN headend routers to the individual remote users, downstream QoS is not enabled in this example. In most instances, with a single user at the home office, the downstream path is rarely congested due to higher data rates of the downstream bandwidth compared to the uplink bandwidth. QoS is enabled in the upstream direction on the remote 881 router.
Home Network Topology
Figure 2 show the home network topology.
Figure 2 Home Network Topology
The Cisco 881W router is directly connected to the cable MODEM/router of the service provider. Note that any network traffic leaving the home network over the broadband connection that does not traverse the Cisco 881W router will not be subject to the QoS service policies and may have a negative impact on the video quality.
Warning
All spouse and child network access and employee network access must be subject to the QoS service policy on the outside (WAN) interface of the CVO router to maintain acceptable video quality. See the Business Ready Teleworker Design Guide for more information.
Measuring Service Levels
While the provisioned bandwidth of the business-class broadband connection is recommended to be at least 2 Mbps uplink, the service level provided by the various ISPs and the enterprise corporate network must also provide a service level sufficient for good video quality.
One tool for measuring these service levels is the CiscoWorks Internetwork Performance Monitor (IPM). IPM uses IP service-level agreements (IP SLAs) probes between two Cisco IOS routers to measure the characteristics of the network. Of importance to both voice and video are latency, jitter, and packet loss.
In this example, IPM is configured to measure these values between the IP addresses of 10.81.0.26 and 10.81.7.25; a dedicated IP SLA router; and the remote Cisco 881W router. These IP addresses are shown in Figure 1. While these two points in the topology provide a reasonably effective measurement of the end-to-end network performance, the true end-to-end statistics can be observed on the Telepresence end-points. In this testing, the remote LAN and the campus LAN environment were not measured by IP SLA. However, latency, jitter, and loss normally are minimal on the LAN segments.
Latency
Minimal network latency contributes to the usability of the TelePresence call. A TelePresence call is a combination of voice-over-IP (VoIP), video-over-IP (VoD), and the optional incorporation of an AUX channel for sharing the computer screen of the participants. High latency impacts the usability of the call, not the audio fidelity or video image clarity, by increasing the likelihood that two participants on the call will both speak at the same time. As latency increases, jitter usually also increases. Typically, jitter is a function of latency.
In this deployment, the observed latency is considered ideal. This internal Cisco deployment has supported full and part-time Teleworkers in the RTP area from 2003 until the present. Latency, loss, and jitter have been monitored and reported over a DSL, cable, and wireless broadband over this period of time. In most cases, one-way latency below 50 milliseconds (ms) is routinely attained. The original V3PN and Teleworker design guides specified 50 ms as the targeted threshold value for latency between the remote home-office and the enterprise campus headend.
In Figure 3, the average round-trip values are reported using Internetwork Performance Monitor.
Figure 3 Observed Round-Trip Latency
The average round-trip latency of 31 ms is a optimal value. Because of the asymmetrical nature of the provisioned bandwidth (15M down / 2 M uplink), it is expected (and observed) that the latency from campus to remote location is lower than from the home-office to the campus. In fact, looking at a manually configured IP SLA udp-jitter probe on the remote Cisco 881W router, the one-way reported latency from destination to source (downlink enterprise campus to remote router) on average, is only a few milliseconds, while the source to destination (uplink) contributes to the majority of the latency budget. The output statistics from the G.729 udp-jitter probe are shown below:
#show ip sla statistics 91 detailsIPSLAs Latest Operation StatisticsIPSLA operation id: 91Latest RTT: 31 millisecondsLatest operation start time: 15:41:17.158 edt Thu Sep 24 2009Latest operation return code: OKRTT Values:Number Of RTT: 50 RTT Min/Avg/Max: 28/31/48 millisecondsLatency one-way time:Number of Latency one-way Samples: 50Source to Destination Latency one way Min/Avg/Max: 27/29/45 millisecondsDestination to Source Latency one way Min/Avg/Max: 1/2/7 millisecondsSource to Destination Latency one way Sum/Sum2: 1467/43503Destination to Source Latency one way Sum/Sum2: 125/399Jitter Time:Number of SD Jitter Samples: 49Number of DS Jitter Samples: 49Source to Destination Jitter Min/Avg/Max: 0/3/16 millisecondsDestination to Source Jitter Min/Avg/Max: 0/2/4 millisecondsSource to destination positive jitter Min/Avg/Max: 1/3/16 millisecondsSource to destination positive jitter Number/Sum/Sum2: 15/50/464Source to destination negative jitter Min/Avg/Max: 1/3/16 millisecondsSource to destination negative jitter Number/Sum/Sum2: 13/49/483Destination to Source positive jitter Min/Avg/Max: 1/1/4 millisecondsDestination to Source positive jitter Number/Sum/Sum2: 16/29/65Destination to Source negative jitter Min/Avg/Max: 1/1/4 millisecondsDestination to Source negative jitter Number/Sum/Sum2: 17/27/59Interarrival jitterout: 1 Interarrival jitterin: 0Over thresholds occurred: FALSEPacket Loss Values:Loss Source to Destination: 0 Loss Destination to Source: 0Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0Packet Skipped: 0Voice Score Values:Calculated Planning Impairment Factor (ICPIF): 11MOS score: 4.06Number of successes: 21Number of failures: 0Operation time to live: ForeverOperational state of entry: ActiveLIn most broadband deployments (especially cable, which operates over a shared media), latency, loss and jitter can be expected to increase during periods of increased activity by other users of the service provider. Typically, the most busy period is between10:00am to 6:00pm local time. This is apparent in the latency chart is shown in Figure 3. While the average latency is maintained within acceptable limits, the average maximum observed values will trend higher during these busy periods. Note, however, that in the section discussing packet loss, the call statistics captured from the campus endpoint are from approximately 2:00pm, which falls within this normally busy period. The latency and loss reported by the receiving CODEC are considered good to exceptional reported values.
Jitter
Jitter is the variation in latency between the voice/video packets as they traverse the network. If jitter is excessive, it may lead to packet loss by the receiving decoder if the packet arrives outside the jitter buffer and is discarded because of late arrival. The packet is received but discarded (RxDisc). Generally, paths with low latency also, on average, exhibit low jitter.
In Figure 4, the average jitter values are reported using Internetwork Performance Monitor.
Figure 4 Destination to Source (Uplink) Jitter
The output from the show ip sla statistics 91 details command in the previous latency section reported average jitter from both directions in the 2 to 3 millisecond range. These reported values are also ideal target values. In the V3PN and Teleworker design guides, the goal was jitter less than 10ms.
Loss
In most deployments, packet loss is attributed to the following:
•
Queue drops—From a shaper or interface buffer, typically, as a result of the available bandwidth on the Teleworker router, but also can be due to congestion in the ISP.
•
Outages—Packet loss is common due to a failed link and while the routing protocol detects and installs an alternate route in the routing table.
•
Received but Discarded (RxDisc)[4]—RxDisc can come from an out-of-order packet or a packet that arrived too late. Most load-sharing techniques do not load-share on a per-packet basis, minimizing the occurrence of out-of-order packets. Late arrival is attributed to high jitter.
•
Faulty hardware or Interface mis-configuration—In Ethernet topologies, a duplex mismatch (one side of the link is half duplex, while the other is full duplex) can exhibit very high percentages of packet loss. Additionally, faulty or failing hardware can contribute to packet loss due to input or CRC errors at the receiving interface. These packet loss issues are not specific to TelePresence and should be identified an corrected as part of the fault detection function of the enterprise network management subsystem.
One observation from pilot testing and the review of output queue drops on the Teleworker router and IO Graphs from packet captures is that most of the packet loss occurred during the first seconds of the call. In testing, network traffic on the local LAN segment is captured. The TelePresence conference (720p Lite) is of a pre-recorded video feed substituted as input to the encoder rather than usual camera input. Slide sharing by way of the AUX port is enabled with a slide change every 10 seconds. Also on the LAN, segment is a PC using HTTP to upload a file. The utilization is shown in Figure 5.
Figure 5 I/O Graph of Voice, Video and Data
QoS is configured on the uplink (HCBWFQ) with the shaper on uplink at 1,800,000 bps with interval at 10ms. Figure 5 illustrates the effectiveness of QoS of managing the video feed over the data traffic. When the video feed is not present on the network, the bandwidth consumed by the PC approaches the capacity limit of the shaper. When the video feed is initiated, the HTTP application throughput decreases accordingly.
The H.264 specification enables two types of I-frames: normal I-frames and IDR frames.[5] The difference is no subsequent frame can reference a frame prior to the IDR frame. At the start of the video feed an IDR frame is generated and these frames create a burst of traffic on the network, as they are completely self-contained and less efficiently compressed than P or B frames.
In Figure 5, labeled restart of video test feed, the video input is solid black while the recorded video feed restarts its loop. During that period, the HTTP throughput increases because the video bandwidth consumption decreases. When the video loop begins again, a burst of traffic is encountered because of the IDR frame. Some packets may be lost during this state change. By modifying the target shaped rate, queue size and Committed Burst size (Bc) / Excess Burst size (Be) this loss could be avoided. However, bandwidth for the Teleworker is a finite resource and attempting to eliminate all video packet-loss may not be economically feasible or practical. The goal is to enable the use of TelePresence where bandwidth is limited by distance and cost. The QoS configuration parameters shown in the next section are a reasonable balance between quality and accessibility.
Note
The loss chart from Internetwork Performance Monitor is not included as the number of packets lost due to drops within the ISP network is too insignificant to be relevant.
The call detail statistics for the campus endpoint using a resolution/quality of 720p Lite (Bit Rate 936000 bps, 720p) provide another data point for determining the network characteristics. The latency values report are one-way and the reported values are from home-office to campus (campus codec), the uplink. The AUX port has a PowerPoint slide transition every 10 seconds. In the following example, key elements are highlighted in blue.
Campus Codecadmin:show call statistics all detailCall StatisticsRegistered to Cisco Unified Communications Manager : YesCall Connected : YesCall Type : Audio/Video Call Call Start Time: Sep 15 13:57:24 2009Duration (sec) : 177 Direction : IncomingLocal Number : 21011 Remote Number : 21010State : Answered Bit Rate : 936000 bps,720pSecurity Level : Non-Secure-- Audio --IP Addr Src : 10.80.33.246:23724 Dst : 10.81.7.30:17720Latency Avg : 17 Period : 16Statistics Left Center Right AuxTx Media Type N/A AAC-LD N/A AAC-LDTx Bytes 0 1462294 0 0Tx Packets 0 8809 0 0Rx Media Type AAC-LD AAC-LD AAC-LD AAC-LDRx Bytes 0 1461310 0 1442044Rx Packets 0 8804 0 8687Rx Packets Lost 0 3 0 2Pkts % Call 0.0000 0.0341 0.0000 0.0230Pkts % Period 0.0000 0.0000 0.0000 0.0000Rx Pkts OOO 0 0 0 0Rx Pkts Dup'd 0 0 0 0Rx Pkts Late 0 3 0 2Rx Pkts AuthFail 0 0 0 0Rx Jitter/Call 0 88 0 107Rx Jitter/Period 0 76 0 74-- Video --IP Addr Src : 10.80.33.246:30762 Dst : 10.81.7.30:17106Latency Avg : 18 Period : 17Statistics Center AuxTx Media Type H.264 H.264Tx Bytes 20682841 0Tx Packets 19255 0Rx Media Type H.264 H.264Rx Bytes 20837715 1232470Rx Packets 20860 1409Rx Packets Lost 15 0Pkts % Call 0.0718 0.0000Pkts % Period 0.0000 0.0000Rx Pkts OOO 0 0Rx Pkts Dup'd 0 0Rx Pkts Late 22 0Rx Pkts AuthFail 0 0Rx Jitter/Call 118 19Rx Jitter/Period 82 11In the above example, the packet loss is less than 1/10th of 1 percent and one-way latency is less than 20 milliseconds. The reported values are from approximately 2:00pm local time, which is normally a busy period for both the Internet as well as the corporate network. These network service levels are considered good to exceptional.
Teleworker Router
This section shows and discusses the configuration excerpts and output of the QoS and interface statistics of the remote Teleworker router.
Cisco Virtual Office
The remote Teleworker router and headend routers are based from a Cisco Virtual Office deployment. For more information, refer to www.cisco.com/web/go/cvo. The router being tested was running Cisco IOS Release 12.4(22)T1 with the Advanced IP Services feature set enabled.
#show ver | inc imageSystem image file is "flash:c880data-universalk9-mz.124-22.T1.bin"#show license featureFeature name Enforcement Evaluation Clear Allowed Enabledadvipservices yes yes yes yesadvsecurity no no yes noThe QoS related show commands in the following section include overhead associated with encrypted tunnels. The DMVPN tunnels are protected with a transform set using 3DES and SHA hash.
#show cry ipsec sa | inc interface|settings|transforminterface: Tunnel100transform: esp-3des esp-sha-hmac ,in use settings ={Transport UDP-Encaps, }interface: Tunnel200transform: esp-3des esp-sha-hmac ,in use settings ={Transport UDP-Encaps, }If the Teleworker router is deployed behind a NAT device, NAT Traversal (NAT-T) is negotiated and is evident from the specification of UDP-Encaps in the above display. Because the QoS policy references DSCP values to classify packets, and that the encryption encapsulation process copies the ToS byte of the plain text packet to the encrypted packet header, qos pre-classify is not required on the tunnel interfaces.
Encryption Overhead
The encryption and encapsulation of the TelePresence calls in DMVPN tunnels adds overhead to the plain text packets. In deployment testing Triple DES (3DES) and SHA are configured. Many deployments are interested in using Advanced Encryption Standard (AES), orRijndael, instead of 3DES because AES supports 128, 192, and 256-bit keys while 3DES supports a 168-bit key with an effective length of 112 bits. AES is an encryption standard adopted by the U.S. government. Encryption must be hardware-accelerated for adequate performance. AES-128, 192, 256, and 3DES all exhibit similar performance when hardware accelerated. Therefore, if AES is chosen, it is practical to use a key length of 256. Figure 6 illustrates the relevant encrypted packet details for both AES and 3DES.
Figure 6 Encrypted Packet Details
This illustration assumes DMVPN (GRE Transport mode) ESP AES-128/SHA or 3DES/SHA with NAT-T.
AES adds slightly more overhead than 3DES. AES uses an Initialization Vector (IV) that is 16 bytes while 3DES uses an IV of 8 bytes. This is a factor of the block size, AES uses a 16-byte block where 3DES uses an 8-byte block. Either encryption algorithm encrypts plain text on a block-by-block basis. If the plain text is not an even multiple of the block size, padding must be added to the plain text to fill the last block.
Assuming a plain text packet of 1,024 bytes, (and therefore no padding of the last block), the resulting encrypted packet would be 1,090 bytes or an approximately 6 to 7 percent increase in packet size. The average packet size of a TelePresence call is over 1,024 bytes per packet.
Quality-of-Service (QoS) Configuration
In this section the QoS configuration of the remote Teleworker router is shown.The Differentiated Services Code Point (DSCP) value from plain text packets are copied to the IP header of the encrypted packet as part of the encapsulation process.
Class Map
The Cisco Medianet Application Classes DiffServ QoS Recommendations (RFC 4594-Based) is configured on the remote router. To accommodate Cisco Unified Video Advantage (formerly known as Cisco VT Advantage), AF41 has been included in the VOICE class as well as CS4 for TelePresence.
!class-map match-any TELEPRESENCEmatch ip dscp cs4class-map match-any LOW-LATENCY-DATAmatch ip dscp af21 af22 af23class-map match-any HIGH-THROUGHPUT-DATAmatch ip dscp af11 af12 af13class-map match-any BROADCAST-VIDEOmatch ip dscp cs5class-map match-any NETWORK-CONTROLmatch ip dscp cs6class-map match-any MULTIMEDIA-CONFERENCINGmatch ip dscp af41 af42 af43class-map match-any OAMmatch ip dscp cs2class-map match-any VOICEmatch ip dscp efmatch ip dscp af41match ip dscp cs4class-map match-any SCAVENGERmatch ip dscp cs1class-map match-any CALL-SIGNALINGmatch ip dscp cs3class-map match-any MULTIMEDIA-STREAMINGmatch ip dscp af31 af32 af33!
Note
Class-default is the 12th class and does not require an explicitly defined class-map statement. This QoS policy assumes the end-user will not be on a VoIP call and a CTS-500 call simultaneously.
Policy Map
In testing the TelePresence network, traffic is shown configured in either a bandwidth queue as well as a priority or Low Latency Queue (LLQ) queue. Either configuration is acceptable and will produce a quality video experience.
The cir value used in testing is a fraction of the provisioned and measured bandwidth. The service provider advertises a 2Mbps uplink. The measured actual throughput of the link is measured at approximately 1.9Mbps. The cir value is configured at approximately 95 percent (1.8Mbps) of the measured uplink throughput. Configuring a shaper cir value at 95 percent of the measured actual throughput is consistent with the Enterprise Class Teleworker [6] design guide. The goal is to shape at a rate which will minimize indiscriminate drops by input policers of the service provider broadband aggregation switches/routers.
The tested and configured shaper measurement intervals (Bc) ranged from 4ms to 25ms, all producing acceptable results. To be consistent with the Enterprise Class Teleworker [6] design guide, a 10ms interval is recommended. The parameters for 4,10 and 25ms are shown in the following examples:
shape average cir [bc] [be]shape average 1800000 45000 45000 25msshape average 1800000 18000 18000 10ms <---- Value illustrated in config samplesshape average 1800000 7200 7200 4ms <--- IOS default valueIf the configuration command does not specify Bc and Be, the default value is a 4 milliseconds measurement interval; therefore, the Bc will be CIR * (4 / 1000)[7].
Bandwidth Queue
The policy-map configuration using the bandwidth queue is shown below:
!policy-map V3PN-teleworkerclass VOICEbandwidth percent 85class CALL-SIGNALINGbandwidth percent 2class NETWORK-CONTROLbandwidth percent 5class class-defaultfair-queuerandom-detect dscp-basedpolicy-map Shaperclass class-defaultshape average 1800000 18000 18000queue-limit 1024 packetsservice-policy V3PN-teleworker!Priority (LLQ) Queue
The policy-map configuration using the priority queue is shown below:
!policy-map V3PN-teleworkerdescription V3PN-teleworkerclass VOICEpriority percent 85class CALL-SIGNALINGbandwidth percent 2class NETWORK-CONTROLbandwidth percent 5class class-defaultfair-queuerandom-detect dscp-basedpolicy-map Shaperclass class-defaultshape average 1800000 18000 18000queue-limit 1024 packetsservice-policy V3PN-teleworker!WAN Interface
The service-policy is applied to the WAN (outside) interface of the Teleworker router. The max-reserved-bandwidth default value of 75 percent must be increased to 100 percent (as shown below) because of the amount of bandwidth required by the TelePresence call.
!interface FastEthernet4description Outsideip address dhcpip access-group INPUT_ACL inip nat outsideip inspect CBAC outip virtual-reassemblymax-reserved-bandwidth 100service-policy output ShaperendDeployment Results
In this section, the output from the show policy-map interface command is included to demonstrate the effectiveness of the QoS service policy. As a baseline, a initial test is run with only the TelePresence call active from the Teleworker router. A capture of this traffic from the LAN interface perspective is shown in Figure 7.
Figure 7 Baseline Test
Figure 7 illustrates that the voice, video, and AUX port (slide sharing) traffic from the CTS-500 is approximately 1.5Mbps of sustained traffic. There is an occasional burst in traffic. In the following subsections, the traffic profile from Figure 5 is demonstrated; TelePresence conference (720p Lite), slide sharing by way of the AUX port, and the PC using HTTP to upload a file.
Bandwidth Queue Configuration
In this example, the voice and video traffic is configured in a bandwidth queue of 85 percent of the 1.8Mbps shaper with a measurement interval of 10ms. The interface statistics show that the combined throughput is approaching the 1.8Mbps value. Recall that the output interface statistics as well as the policy-map values include the encryption overhead.
#show interfaces fastEthernet 4 | include rate30 second input rate 1323000 bits/sec, 225 packets/sec30 second output rate 1799000 bits/sec, 303 packets/secThe parent shaper policy-map shows the shaper active by the presence of packets currently queued. Note that the TelePresence network traffic is matching DSCP AF41 rather than CS4. The marking of CS4 is recommended by the Cisco Medianet Application Classes DiffServ QoS Recommendation. However, in this implementation, the network manager has decided to mark both TelePresence and Cisco Unified Video Advantage (CUVA) as AF41.
#show policy-map interface fastEthernet 4FastEthernet4Service-policy output: ShaperClass-map: class-default (match-any)96168 packets, 95948483 bytes30 second offered rate 1799000 bps, drop rate 3000 bpsMatch: anyQueueingqueue limit 1024 packets(queue depth/total drops/no-buffer drops) 26/322/0(pkts output/bytes output) 95846/95554955shape (average) cir 1800000, bc 18000, be 18000target shape rate 1800000Service-policy : V3PN-teleworkerClass-map: VOICE (match-any)47749 packets, 32302766 bytes30 second offered rate 1437000 bps, drop rate 0 bpsMatch: ip dscp ef (46)0 packets, 0 bytes30 second rate 0 bpsMatch: ip dscp af41 (34)47749 packets, 32302766 bytes30 second rate 1437000 bpsMatch: ip dscp cs4 (32)0 packets, 0 bytes30 second rate 0 bpsQueueingqueue limit 64 packets(queue depth/total drops/no-buffer drops) 1/20/0(pkts output/bytes output) 47730/32286500bandwidth 85% (1530 kbps)Class-map: CALL-SIGNALING (match-any))[omitted]Class-map: NETWORK-CONTROL (match-any)[omitted]Class-map: class-default (match-any)47401 packets, 63490483 bytes30 second offered rate 360000 bps, drop rate 3000 bpsMatch: anyQueueingqueue limit 64 packets(queue depth/total drops/no-buffer drops/flowdrops) 23/302/0/0(pkts output/bytes output) 47101/63103185Fair-queue: per-flow queue limit 16Exp-weight-constant: 9 (1/512)Mean queue depth: 19 packetsdscp Transmitted Random drop Tail/Flow drop Minimum Maximum Markpkts/bytes pkts/bytes pkts/bytes thresh thresh probdefault 54020/68936025 329/428374 0/0 20 40 1/10cs5 561/79398 0/0 0/0 30 40 1/10In class-default, Weighted RED (WRED) is enabled and the best effort class drops are random rather than tail drops. Approximately 360K of HTTP traffic is active on the uplink.
Priority Queue Configuration
The priority queue configuration demonstrates similar results to the previous example.
#show policy-map interface fastEthernet 4FastEthernet4Service-policy output: ShaperClass-map: class-default (match-any)55226 packets, 48774960 bytes30 second offered rate 1788000 bps, drop rate 3000 bpsMatch: anyQueueingqueue limit 1024 packets(queue depth/total drops/no-buffer drops) 28/107/0(pkts output/bytes output) 55068/48592668shape (average) cir 1800000, bc 18000, be 18000target shape rate 1800000Service-policy : V3PN-teleworkerqueue stats for all priority classes:Queueingqueue limit 64 packets(queue depth/total drops/no-buffer drops) 0/51/0(pkts output/bytes output) 36690/24813756Class-map: VOICE (match-any)36741 packets, 24868798 bytes30 second offered rate 1330000 bps, drop rate 0 bpsMatch: ip dscp ef (46)0 packets, 0 bytes30 second rate 0 bpsMatch: ip dscp af41 (34)36741 packets, 24868798 bytes30 second rate 1330000 bpsMatch: ip dscp cs4 (32)0 packets, 0 bytes30 second rate 0 bpsPriority: 85% (1530 kbps), burst bytes 38250, b/w exceed drops: 51The remaining output display is eliminated for brevity.
Summary
In summary, this pilot program has demonstrated that a CTS-500 using 720p Lite can effectively be implemented on a business-class broadband connection when provisioned with a recommended minimum of 2 Mbps uplink. The 720p Lite configuration requires approximately 1.5Mbps with the overhead of DMVPN/IPSec using 3DES/SHA in transport mode.
As a best practice, the broadband connection should be speed tested and the shaper should be configured with an average cir value of approximately 95 percent of the measured bandwidth. In testing, a shaper of 1.8Mbps was used on a service advertised as 2.0 Mbps and measured at 1.9Mbps.
It is important to use network management tools such as the CiscoWorks Internetwork Performance Monitor and IP SLA to measure the network performance on an ongoing-basis to verify that the service provider continues to offer the subscribed bandwidth. As guideline, latency (one-way) should be less than 50 ms, jitter less than 10 ms, and packet loss less than 1/2 of the 1 percent for an effective user experience.
It must be emphasized that the service level of broadband providers and the Internet in general will vary by time of day. Usage usually increases mid-morning to early evening. Additionally, in periods of area-wide disasters, which increase telecommuting load, expect that the service levels may be adversely impacted.
References
•
[1] Cisco TelePresence System 500 Datasheet, Retrieved 25 September 2009, from the following URL: http://www.cisco.com/en/US/prod/collateral/ps7060/ps8329/ps8330/ps9599/data_sheet_c78-468517.html
•
[2] Virtual Office - Cisco Systems, Retrieved 25 September 2009, from the following URL: http://www.cisco.com/web/go/cvo
•
[3] 1918 flu pandemic From Wikipedia, the free encyclopedia, Retrieved 25 September 2009 from the following URL: http://en.wikipedia.org/wiki/1918_flu_pandemic
•
[4] Cisco Unified Communications—Poor Voice Quality, Retrieved 25 September 2009 from URL http://docwiki.cisco.com/wiki/Cisco_Unified_Communications_--_Poor_Voice_Quality
•
[5] Understanding H.264 Encoding Parameters - I, P and B-frames, Jan Ozer, Published 06/8/2009, Retrieved 25 September 2009 from the following URL: http://www.streaminglearningcenter.com/articles/41/4/Producing-H264-Video-for-Flash-An-Overview/Page4.html
•
[6] Business Ready Teleworker Design Guide, January 2004, Retrieved 25 September 2009 from the following URL: http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008074f24a.pdf
•
[7] Cisco IOS Quality of Service Solutions Command Reference, Release 12.2, Retrieved 25 September 2009 from the following URL: http://www.cisco.com/en/US/docs/ios/12_2/qos/command/reference/qrfcmd9.html#wp1077189








