Buffer Sizes and Delays
VQE-C default settings for buffer sizing and delays are designed to work out of the box for typical deployment scenarios. The information provided in this section explains the current operation of the jitter buffer. Some or all of these parameters may not be supported in future releases of the VQE-C. The buffering and timing used by the VQE-C for repairing and reordering packets can be configured based on the requirements of the deployment scenario. Some important factors to consider are the memory available to the VQE-C, CPU speed of the platform running the VQE-C, and round-trip latency between the VQE-C and the VQE Server (VQE-S).
Because the VQE-C offers two different active error repair strategies (Forward Error Correction [FEC] and Unicast Retransmission) and also provides packet reordering services for out-of-order packets, there are several different cases that should be considered when determining buffer sizes and delays. This section explains methods for configuring the VQE-C for each of these cases.
Be aware that these features are only operational when they are enabled on both the VQE-C and the VQE-S, as specified by the Session Description Protocol (SDP) channel configurations being used. Also, regardless of other features that may or may not be enabled, reordering services are always provided by VQE-C.
Note The following conventions apply to the diagrams in the succeeding sections:
– Grayed out blocks are shown for context and the sake of comparison between diagrams, but in function, these grayed out blocks do not exist for that particular case.
– Units for the quantities and horizontal axes are all in units of time (specified as milliseconds in the configuration of VQE-C).
Reordering only is the simplest case of buffer timing and delays because there are no error repair services. When error repair is not used on channels in the channel lineup, reordering of out-of-order packets is still available. If the VQE-C parameter integrated_rtp_fallback is set to TRUE, the VQE-C also provides reordering for Real-time Transport Protocol (RTP) streams not configured within the channel lineup. Figure 2-1 illustrates buffer timing and delays when only reordering is used.
Figure 2-1 VQE-C Buffer Timing and Delays: Reordering Only
The VQE-C holds all received in-order packets for a duration of the length of the reorder delay. The reorder delay is specified with the VQE-C parameter reorder_delay_abs (a time period in milliseconds). Any packets that arrive out-of-order within this time period are put into the correct order when they are played out to the decoder.
For more information on the reorder_delay_abs parameter, see the “reorder_delay_abs” section.
Unicast Retransmission Error Repair Only
When only Unicast Retransmission error repair is used on streams in the channel lineup, missing packets are fixed using retransmission-based error repair once per every repair interval. Figure 2-2 illustrates buffer timing and delays when only Unicast Retransmission is used.
Figure 2-2 VQE-C Buffer Timing and Delays: Unicast Retransmission Only
The error repair interval is specified with the VQE-C parameter repair_trigger_point_abs (a time period in milliseconds). The packets that the VQE attempts to fix during each error repair interval are those that have been known about for a time period greater than the reorder delay. In other words, the packets eligible to be fixed by Unicast Retransmission are those between points C and D in Figure 2-2 that have not already been eligible during a previous repair interval. VQE does not attempt to fix the same missing packets more than once.
The jitter buffer must be sized large enough to allow the longest desired burst rate to be received. The calculation of the jitter buffer size must allow for all sources of error including scheduling delays on the processor. Precisely tuning the size of the jitter buffer is not recommended, but the size of the jitter buffer must be made large enough to allow time for repair packets to arrive at the oversubscription rate.
For more information on the repair_trigger_point_abs and jitter_buff_size parameters, see the “repair_trigger_point_abs” section and the “jitter_buff_size” section.
Forward Error Correction Only
When only FEC is used, the effective length of the internal jitter buffer is equal to the duration of the reorder delay. The value of the jitter_buff_size parameter is ignored in this case. Figure 2-3 illustrates buffer timing and delays when only FEC is used.
Figure 2-3 VQE-C Buffer Timing and Delays: FEC Only
FEC attempts to repair any missing packets, and if it fails, these packets cannot be sent to the decoder and are effectively played out as packet loss. It is determined that FEC has failed to fix a particular packet if the place for the missing packet has passed through the FEC delay (goes beyond point B in Figure 2-3) without having been fixed.
The VQE-C calculates the FEC delay using the L and D values of the FEC scheme, and the average packet time of the stream. The average packet time is the average time that elapses between the reception of consecutive packets. FEC delay is calculated as follows:
FEC delay = (2 x L x D) x (average packet time)
In the preceding calculation, (2 x L x D) is the maximum range (in packets) in which FEC can recover missing packets.
FEC and Unicast Retransmission Error Repair
When Unicast Retransmission and FEC are used on streams in the channel lineup, FEC attempts to fix any missing packets in the primary stream. If FEC is not able to repair the packets, Unicast Retransmission error repair attempts to fix them. Figure 2-4 illustrates buffer timing and delays when FEC and Unicast Retransmission are used.
Figure 2-4 VQE-C Buffer Timing and Delays: FEC and Unicast Retransmission Error Repair
Unicast Retransmission error repair is attempted once per error repair interval. It attempts to fix all missing packets that meet the following two conditions:
- FEC has failed to repair the missing packets.
- Missing packets have been known about for a time period greater than the reorder delay.
Therefore, the packets eligible for Unicast Retransmission error repair are those that are still missing between points C and D in Figure 2-4.
Buffer Size Constraint
The sum of the time values of reorder delay, repair trigger time, and the round-trip time between the VQE-C and the VQE-S must be less than the jitter buffer size. If the sum is not less, some gaps may not be fixed before being played out to the decoder. This constraint can be modeled by the equation:
(reorder delay) + (repair trigger time) + (round-trip time) < jitter buffer size
This equation represents the minimum requirement for successful error repair; however, the optimal configuration values are dependent on the given deployment. If the sum of the reorder delay, repair trigger time, and round-trip time are greater than the jitter buffer size for a particular deployment (that is, the minimum requirement is not met), this failure is observable as follows:
- Missing packets on the output of the VQE-C
- “Late packet” counter in VQE-C is likely to increase over time
In this situation, the repair packets are not getting back to the VQE-C in time to be played out in the correct order.
To resolve this, you should make one or more of the following modifications to the configuration parameters:
- Reduce the value of reorder_delay_abs.
- Reduce the value of repair_trigger_point_abs.
- Increase the value of jitter_buff_size.
When making modifications to these parameters, keep in mind how they affect timing and VQE-C memory use as explained in the preceding sections.
Configuration Delivery Infrastructure
The configuration delivery infrastructure (CDI) is used to deliver network and channel configuration information to the VQE Clients in a VQE system. Deploying the CDI requires the setup and configuration of one or more VQE-C Configuration Delivery Servers (VCDSs), network infrastructure (for example, Domain Name System servers), and VQE-C devices.
The following sections describe the CDI setup and configuration.
Note In place of a VCDS server, an RTSP server that is compatible with the VQE CDI can be used. For simplicity, this discussion makes references only to VCDS.
VQE-C Channel Configuration Delivery Server
The VQE-C Channel Configuration Delivery Server (VCDS) is responsible for storing and delivering channel configuration files and network configuration files to the VQE-C devices. The network configuration files support group-based customization. Each device executing the VQE-C has a unique identifier (for example, MAC address) that is included in the request to the VCDS. On the VCDS, a client database file associates each VQE-C unique identifier with a group identifier that specifies the set of attributes that should be applied to the VQE-C system configuration.
For example, the ability to provision VQE-C on a per-device basis could allow a service provider to partition devices into groups and provision the groups of devices as follows:
- One group with no VQE services enabled
- One group with only Unicast Retransmission enabled
- One group with only Rapid Channel Change enabled
- One group with both Unicast Retransmission and Rapid Channel Change enabled
For more information about the VCDS role in delivering network configuration files to VQE Clients, see the Cisco CDA Visual Quality Experience Application User Guide.
Dynamic Host Configuration Protocol (DHCP) and DNS servers must be configured so that they work correctly with VCDS. For example, to learn the identities of the VCDS devices that supply configuration files to a VQE-C, a DNS server must be configured to return the VCDS server name to the VQE-C.
For details on the setup and configuration of a DNS server for VQE-C to use, see the Cisco CDA Visual Quality Experience Application User Guide.
The VQE-C can be configured to use the configuration delivery infrastructure by setting the VQE-C parameter cdi_enable to TRUE. With cdi_enable set to TRUE, configuration updates are enabled and are configured further as follows:
- network_cfg_pathname—When this parameter is configured, the VQE-C attempts to retrieve network configuration updates from a VCDS, apply them during initialization, and cache them to the filesystem. When this parameter is not configured, the VQE-C does not retrieve or apply network configuration updates, relying on its system configuration file instead.
- channel_lineup—When this parameter is configured, the VQE-C attempts to cache channel updates to the filesystem. When this parameter is not configured, channel lineup updates are attempted, but are not cached to a file.
If configured to do so, the VQE-C attempts to retrieve updated network and channel configuration files during initialization. If an updated configuration is available, the VQE-C downloads the update from the VCDS, writes it to a file (if applicable), and applies it before initializing. If the VCDS cannot be reached, or if the VQE-C already has the most up-to-date configuration in its cache, the cached network configuration and channel configuration is used during initialization.
Following initialization, the VQE-C can be configured to periodically poll a VCDS for configuration updates with the VQE-C parameter update_interval_max. The value of update_interval_max controls the frequency of the update attempts for both the network configuration file and channel configuration file. The update_window parameter adds a small randomized component to the total interval between updates to prevent synchronization of updates within a network.
As with updates made during initialization, these background update requests are sent and any updates from VCDS cached for a particular configuration file (network or channel) depending on the values of the VQE-C parameters network_cfg_pathname and channel_lineup, respectively. Background network configuration and channel updates typically take effect for a channel the next time it is tuned by the STB. For network configuration updates, see the "Changes Effective Upon" field of each parameter in the “VQE-C Configuration Parameters: Usage Guidance” section.
Update requests can be explicitly triggered when the VQE-C is asked to bind a tuner to a channel which is not present in its channel lineup. Updates can only be triggered in this situation if the update_interval_max parameter is set to 0.
Update requests may also be triggered if the VQE-C detects that an unexpected mismatch in the configuration file's checksum and original checksum provided during download. This triggered update only occurs if the index_cfg_pathname parameter has been configured.
In the case which a download configuration file's checksum does not match the checksum in the index file specified by the index_cfg_pathname, then the VQE-C does not use that configuration file.
Remote Configuration Delivery Server
Cisco’s VQE solution supports alternative mechanisms to the VCDS and the CDI for deploying channel and network configuration files that integrate with customized middleware of third-party vendors. From Cisco’s VQE Channel Provisioning Tool (VCPT), it is possible to send channel configuration files to a remote server. Through integration with a middleware solution, a remote server can be used to distribute network and channel configuration files to the VQE-C. The remote server can also be extended to deploy override configuration file, containing per-subscriber configuration changes, to an external application on the STB that, in turn, delivers the override configuration file to the VQE-C.