Guest

Design Zone for TelePresence

Implementing TelePresence over Broadband

  • Viewing Options

  • PDF (940.7 KB)
  • Feedback
Implementing TelePresence over Broadband

Table Of Contents

Implementing TelePresence over Broadband

Contents

Overview

Components

Network Topology

WAN Network Topology

Home Network Topology

Measuring Service Levels

Latency

Jitter

Loss

Teleworker Router

Cisco Virtual Office

Encryption Overhead

Quality-of-Service (QoS) Configuration

Class Map

Policy Map

WAN Interface

Deployment Results

Bandwidth Queue Configuration

Priority Queue Configuration

Summary

References


Implementing TelePresence over Broadband


Published: 10/20/09

Contents

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 planningTravel 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  details   
IPSLAs Latest Operation Statistics

IPSLA operation id: 91
        Latest RTT: 31 milliseconds
Latest operation start time: 15:41:17.158 edt Thu Sep 24 2009
Latest operation return code: OK
RTT Values:
        Number Of RTT: 50               RTT Min/Avg/Max: 28/31/48 milliseconds
Latency one-way time:
        Number of Latency one-way Samples: 50
        Source to Destination Latency one way Min/Avg/Max: 27/29/45 milliseconds
        Destination to Source Latency one way Min/Avg/Max: 1/2/7 milliseconds
        Source to Destination Latency one way Sum/Sum2: 1467/43503
        Destination to Source Latency one way Sum/Sum2: 125/399
Jitter Time:
        Number of SD Jitter Samples: 49
        Number of DS Jitter Samples: 49
        Source to Destination Jitter Min/Avg/Max: 0/3/16 milliseconds
        Destination to Source Jitter Min/Avg/Max: 0/2/4 milliseconds
        Source to destination positive jitter Min/Avg/Max: 1/3/16 milliseconds
        Source to destination positive jitter Number/Sum/Sum2: 15/50/464
        Source to destination negative jitter Min/Avg/Max: 1/3/16 milliseconds
        Source to destination negative jitter Number/Sum/Sum2: 13/49/483
        Destination to Source positive jitter Min/Avg/Max: 1/1/4 milliseconds
        Destination to Source positive jitter Number/Sum/Sum2: 16/29/65
        Destination to Source negative jitter Min/Avg/Max: 1/1/4 milliseconds
        Destination to Source negative jitter Number/Sum/Sum2: 17/27/59
        Interarrival jitterout: 1       Interarrival jitterin: 0
        Over thresholds occurred: FALSE
Packet Loss Values:
        Loss Source to Destination: 0           Loss Destination to Source: 0
        Out Of Sequence: 0      Tail Drop: 0    Packet Late Arrival: 0
Packet Skipped: 0
Voice Score Values:
        Calculated Planning Impairment Factor (ICPIF): 11
MOS score: 4.06
Number of successes: 21
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
L

In 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 Codec
admin:show call statistics all detail

          Call Statistics
Registered to Cisco Unified Communications Manager : Yes
Call Connected            : Yes

Call Type           : Audio/Video Call    Call Start Time: Sep 15 13:57:24 2009
Duration (sec)      : 177                 Direction      : Incoming
Local Number        : 21011               Remote Number  : 21010
State               : Answered            Bit Rate       : 936000 bps,720p
Security Level      : Non-Secure

   -- Audio --
IP Addr   Src : 10.80.33.246:23724       Dst    : 10.81.7.30:17720
Latency   Avg : 17                       Period : 16

Statistics                  Left          Center           Right             Aux
Tx Media Type                N/A          AAC-LD             N/A          AAC-LD
Tx Bytes                       0         1462294               0               0
Tx Packets                     0            8809               0               0
Rx Media Type             AAC-LD          AAC-LD          AAC-LD          AAC-LD
Rx Bytes                       0         1461310               0         1442044
Rx Packets                     0            8804               0            8687
Rx Packets Lost                0               3               0               2
 Pkts % Call              0.0000          0.0341          0.0000          0.0230
 Pkts % Period            0.0000          0.0000          0.0000          0.0000
Rx Pkts OOO                    0               0               0               0
Rx Pkts Dup'd                  0               0               0               0
Rx Pkts Late                   0               3               0               2
Rx Pkts AuthFail               0               0               0               0
Rx Jitter/Call                 0              88               0             107
Rx Jitter/Period               0              76               0              74

-- Video --
IP Addr   Src : 10.80.33.246:30762       Dst    : 10.81.7.30:17106
Latency   Avg : 18                       Period : 17

Statistics                                Center                             Aux
Tx Media Type              H.264           H.264
Tx Bytes                                20682841                               0
Tx Packets                                 19255                               0
Rx Media Type              H.264           H.264
Rx Bytes                                20837715                         1232470
Rx Packets                                 20860                            1409
Rx Packets Lost                               15                               0
 Pkts % Call                              0.0718                          0.0000
 Pkts % Period                            0.0000                          0.0000
Rx Pkts OOO                                    0                               0
Rx Pkts Dup'd                                  0                               0
Rx Pkts Late                                  22                               0
Rx Pkts AuthFail                               0                               0
Rx Jitter/Call                               118                              19
Rx Jitter/Period                              82                              11

In 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 image
System image file is "flash:c880data-universalk9-mz.124-22.T1.bin"

#show license feature 
Feature name             Enforcement  Evaluation  Clear Allowed  Enabled
advipservices            yes          yes         yes            yes  
advsecurity              no           no          yes            no   

The 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|transform
interface: Tunnel100
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Transport UDP-Encaps, }
interface: Tunnel200
        transform: 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 TELEPRESENCE
 match ip dscp cs4 
class-map match-any LOW-LATENCY-DATA
 match ip dscp af21  af22  af23 
class-map match-any HIGH-THROUGHPUT-DATA
 match ip dscp af11  af12  af13 
class-map match-any BROADCAST-VIDEO
 match ip dscp cs5 
class-map match-any NETWORK-CONTROL
 match ip dscp cs6 
class-map match-any MULTIMEDIA-CONFERENCING
 match ip dscp af41  af42  af43 
class-map match-any OAM
 match ip dscp cs2 
class-map match-any VOICE
 match ip dscp ef 
 match ip dscp af41 
 match ip dscp cs4 
class-map match-any SCAVENGER
 match ip dscp cs1 
class-map match-any CALL-SIGNALING
 match ip dscp cs3 
class-map match-any MULTIMEDIA-STREAMING
 match 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    25ms
shape average 1800000 18000 18000    10ms   <---- Value illustrated in config samples
shape average 1800000  7200  7200     4ms   <--- IOS default value

If 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-teleworker
 class VOICE
    bandwidth percent 85
 class CALL-SIGNALING
    bandwidth percent 2
 class NETWORK-CONTROL
    bandwidth percent 5
 class class-default
    fair-queue
     random-detect dscp-based
policy-map Shaper
 class class-default
    shape average 1800000 18000 18000
    queue-limit 1024 packets
  service-policy V3PN-teleworker
!

Priority (LLQ) Queue

The policy-map configuration using the priority queue is shown below:

!
policy-map V3PN-teleworker
 description V3PN-teleworker
 class VOICE
    priority percent 85
 class CALL-SIGNALING
    bandwidth percent 2
 class NETWORK-CONTROL
    bandwidth percent 5
 class class-default
    fair-queue
     random-detect dscp-based
policy-map Shaper
 class class-default
    shape average 1800000 18000 18000
    queue-limit 1024 packets
  service-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 FastEthernet4
 description Outside
 ip address dhcp
 ip access-group INPUT_ACL in
 ip nat outside
 ip inspect CBAC out
 ip virtual-reassembly
 max-reserved-bandwidth 100
 service-policy output Shaper
end

Deployment 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 rate
  30 second input rate 1323000 bits/sec, 225 packets/sec
  30 second output rate 1799000 bits/sec, 303 packets/sec

The 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 4
 FastEthernet4

  Service-policy output: Shaper

    Class-map: class-default (match-any)
      96168 packets, 95948483 bytes
      30 second offered rate 1799000 bps, drop rate 3000 bps
      Match: any
      Queueing
      queue limit 1024 packets
      (queue depth/total drops/no-buffer drops) 26/322/0
      (pkts output/bytes output) 95846/95554955
      shape (average) cir 1800000, bc 18000, be 18000
      target shape rate 1800000

      Service-policy : V3PN-teleworker

        Class-map: VOICE (match-any)
          47749 packets, 32302766 bytes
          30 second offered rate 1437000 bps, drop rate 0 bps
          Match: ip dscp ef (46)
            0 packets, 0 bytes
            30 second rate 0 bps
          Match: ip dscp af41 (34)
            47749 packets, 32302766 bytes
            30 second rate 1437000 bps
          Match: ip dscp cs4 (32)
            0 packets, 0 bytes
            30 second rate 0 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 1/20/0
          (pkts output/bytes output) 47730/32286500
          bandwidth 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 bytes
          30 second offered rate 360000 bps, drop rate 3000 bps
          Match: any
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops/flowdrops) 23/302/0/0
          (pkts output/bytes output) 47101/63103185
          Fair-queue: per-flow queue limit 16
            Exp-weight-constant: 9 (1/512)
            Mean queue depth: 19 packets
            dscp     Transmitted       Random drop      Tail/Flow drop Minimum Maximum 
Mark
                      pkts/bytes    pkts/bytes       pkts/bytes    thresh  thresh  prob

            default    54020/68936025      329/428374 0/0 20            40  1/10
               cs5          561/79398           0/0 0/0 30            40  1/10


In 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 4
 FastEthernet4

  Service-policy output: Shaper

    Class-map: class-default (match-any)
      55226 packets, 48774960 bytes
      30 second offered rate 1788000 bps, drop rate 3000 bps
      Match: any
      Queueing
      queue limit 1024 packets
      (queue depth/total drops/no-buffer drops) 28/107/0
      (pkts output/bytes output) 55068/48592668
      shape (average) cir 1800000, bc 18000, be 18000
      target shape rate 1800000

      Service-policy : V3PN-teleworker

        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/51/0
          (pkts output/bytes output) 36690/24813756

        Class-map: VOICE (match-any)
          36741 packets, 24868798 bytes
          30 second offered rate 1330000 bps, drop rate 0 bps
          Match: ip dscp ef (46)
            0 packets, 0 bytes
            30 second rate 0 bps
          Match: ip dscp af41 (34)
            36741 packets, 24868798 bytes
            30 second rate 1330000 bps
          Match: ip dscp cs4 (32)
            0 packets, 0 bytes
            30 second rate 0 bps
          Priority: 85% (1530 kbps), burst bytes 38250, b/w exceed drops: 51

The 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