Dynamic Acceleration Configuration Reference

Download

Focus Mode

Font Size

Last updated: 2026-06-12 16:48:40

I. Overview
Dynamic acceleration refers to the SDK continuously monitoring network quality and automatically recommending enabling acceleration only when the network deteriorates, and recommending disabling it after the network recovers. This approach saves acceleration traffic costs while ensuring a good user experience. The core questions for dynamic acceleration are only two: when to enable it and when to disable it. This document aims to help you understand the policy configuration logic for dynamic acceleration and the selection and adjustment of acceleration parameters in different scenarios.
II. Core Concepts
1. Three Key Dimensions
Before configuring dynamic acceleration, you need to understand three dimensions that are independent of each other but have recommended pairing relationships:
Dynamic acceleration is applicable to scenarios such as gaming, TRTC, and live streaming.
You can select from the following modes: Multi-Send Single-Receive (Dual-Send), Real-Time (RTC), and Aggregation.
Dynamic acceleration policies include the detection initiation policy, the fast start policy, the dynamic fallback-to-origin policy, and the recommended disable policy.
2. Recommended Pairings of Scenarios and Modes
The following are verified recommended pairings (not mandatory). Generally, using the recommended pairing yields the best results.
Scenario
Recommended Mode
Reason
Typical Customer
Games (FPS/MOBA)
Multi-Send and Selective Receive (Dual-Send)
Small packet traffic, pursuing extremely low latency
Mobile MOBA Games
Real-time audio and video communication
Real-time mode (RTC)
Audio and video streams have high requirements for continuity.
Audio Call
Video Conference
Live streaming
Aggregation mode
High bandwidth requirement, aggregating multiple channels
Gaming
Outdoor Live Streaming
III. Policy Details
The four policies cover the complete decision-making chain for dynamic acceleration, from enabling to disabling:
Policy
Problem to Solve
Post-Trigger Action
Probe Startup Policy
Network performance continues to degrade, requiring acceleration to be enabled.
After the client is called back, the decision is made by the customer.
Quick Startup Policy
Network performance deteriorates abruptly, requiring immediate acceleration.
After the client is called back, the decision is made by the customer.
Dynamic Fallback-to-Origin Policy
The acceleration link performs worse than the direct connection.
The SDK automatically falls back to a direct connection.
Recommended Disable Policy
Network recovers, and acceleration is no longer necessary.
After the client is called back, the decision is made by the customer.
Note:
Policy configuration is independent of the mode. The difference between different scenarios and modes is mainly reflected in the recommended values for policy parameters, while the policy logic itself is universal.
1. Probe Startup Policy
The SDK continuously monitors network quality. When metrics consistently exceed thresholds over a period of time, it calls back to the client to recommend enabling acceleration. This is a progressive detection method, suitable for identifying trends of network deterioration. Decision logic: If, within the [Time Window], the average latency exceeds the threshold, or the jitter exceeds the threshold, or the packet loss rate exceeds the threshold (any one of the three conditions is met), a callback is triggered. In simple terms, if the latency is too high/the jitter is too large/packet loss is too severe over the past X seconds, enabling acceleration is recommended. The table below provides recommended parameter values.
Parameter
Meaning
Gaming Scenarios
Real-time audio and video communication
Streaming Scenarios
Time window
Observation time window
8s
8s
Enable at all times (no configuration required).
Latency threshold
Triggers when average latency exceeds this threshold.
60ms
80ms
-
Jitter threshold
Triggers when latency jitter exceeds this threshold.
15ms
20ms
-
Packet loss threshold
Triggers when packet loss rate exceeds this threshold.
5%
5%
-
Note:
For gaming scenarios, thresholds are set lower because gaming is extremely sensitive to latency (lag can be perceived at 60ms), requiring earlier triggering. For live streaming scenarios, due to high and sustained bandwidth demands, it is recommended to enable acceleration at all times, eliminating the need for detection-based triggering.
2. Quick Startup Policy
Complementary to the detection initiation policy, the detection initiation policy is a trend judgment based on an 8-second window, while the fast start policy is an emergency judgment based on a 2-second window. When the network suddenly and severely deteriorates (such as entering an elevator and Wi-Fi disconnection), the fast start policy can trigger more quickly. Both policies are active simultaneously, and a callback is initiated if either one triggers. Decision logic: If, within the [Time Window], the latency exceeds the [Latency Threshold], a trigger is activated. Note that the fast start policy only monitors the latency metric (not jitter or packet loss), has a shorter window and a higher threshold, and is specifically designed to capture sudden deterioration. The table below provides recommended parameter values.
Parameter
Meaning
﻿
Gaming Scenarios
Real-time audio and video communication
Streaming Scenarios
Time window
Detection window duration
﻿
2s
2s
Enable at all times (recommended)
Latency threshold
Triggers when latency exceeds this threshold.
﻿
80ms
100ms
-
The comparison between the detection initiation policy and the fast start policy is as follows:
Compare
Probe Initiation
Fast Startup
Window / Metric
8s / latency + jitter + packet loss
2s / latency only
Trigger Threshold
Lower (sensitive)
Higher (to prevent false triggers)
Positioning
Detect a continuously deteriorating trend.
Detect sudden performance degradation events.
3. Dynamic Fallback-to-Origin Policy
Protection mechanism: After acceleration is enabled, if the acceleration link itself encounters severe issues (worse than a direct connection), the SDK automatically falls back traffic to the direct primary link to prevent acceleration from causing further lag. Difference from the recommended disable policy: Dynamic fallback-to-origin is a protection action automatically executed by the SDK (without waiting for customer decision), while recommended disable notifies the customer, who then makes the decision. The trigger conditions are as follows (if any one is met, automatic fallback-to-origin occurs).
Condition
Judgment Rule
Plain Meaning
Condition 1: Complete Disconnection
Triggered when consecutive packet loss on the acceleration link reaches the [consecutive packet loss count] threshold, and the primary link is not simultaneously disconnected.
The acceleration link is down, but the direct connection is still up. Fallback should be performed immediately.
Condition 2: Extremely High Latency
Triggered when the latency of [consecutive high-latency packet count] consecutive packets on the acceleration link is ≥ [single-packet latency upper limit] ms.
The link is not down, but the latency is already too high to be acceptable.
Condition 3: Persistently Worse Than Direct Connection
Triggered when, within the [evaluation window], the average acceleration latency is greater than the primary link latency multiplied by [latency ratio threshold]%, and the average acceleration latency is greater than [minimum latency threshold] ms.
Long-term observation shows that using the acceleration link is worse than using the direct connection, and the latency is indeed not low.
Note:
Why is a minimum latency threshold required in Condition Three? It is to avoid false positives. For example, if the primary link latency is 10ms and the accelerated link latency is 12ms, the 12ms latency exceeds 110% of the primary link. However, a 12ms latency itself is entirely acceptable and should not trigger a fallback-to-origin. Adding a minimum threshold (66ms) can filter out such cases.
Recommended parameter values for each scenario are as follows.
Condition
Parameter
Game (Multi-Send Selective-Receive)
TRTC
Condition 1
Consecutive packet loss quantity
4 packets
4 packets
Condition 2
Consecutive high-latency packet quantity
4 packets
Disabled
﻿
Maximum single-packet latency
400ms
-
Condition 3
Evaluation window duration
60 seconds
60 seconds
﻿
Latency ratio threshold
110%
110%
﻿
Minimum latency threshold
66ms
66ms
Streaming/aggregation mode
Enable only Condition 1 (number of consecutive packet losses = 4), and disable Condition 2 and Condition 3.
﻿
﻿
Note:
For real-time scenarios, Condition Two is not enabled because the RTC protocol has its own retransmission mechanism. For aggregation mode, latency-based conditions (Two and Three) are not enabled because aggregation inherently introduces higher latency.
4. Recommended Disable Policy
When acceleration is no longer necessary or physical conditions do not support it, the SDK calls back to the client to recommend disabling acceleration. The client can choose to accept or ignore the recommendation.
The trigger conditions are as follows (if any one is met, a callback recommendation is issued).
Condition
Judgment Rule
Plain Meaning
Condition 1: Only One Network Interface Remaining.
If only one network interface is available, it is recommended to disable the feature after [waiting duration] seconds have passed.
Multipath transmission requires at least two network interfaces. Acceleration is meaningless when only one remains.
Condition 2: No Network Available
If no network interface is available, it is recommended to disable the feature immediately.
Acceleration should be turned off when there is no network.
Condition 3: Long-Term Poor Performance
Triggered when, within the [quality evaluation window], the acceleration latency is greater than the primary link latency multiplied by [latency ratio threshold]%, and the jitter is greater than the primary link jitter multiplied by [jitter ratio threshold]%.
Long-term acceleration performance is worse than that of the direct connection. Turning it off saves costs.
Condition 4: All Secondary Links Down
Triggered when all secondary links experience packet loss within [measurement window] seconds.
All secondary network interfaces experience access timeout, making acceleration meaningless.
Recommended parameter values for each scenario are as follows. (For live streaming/aggregation mode: Only enable Condition One (wait 10 seconds) and Condition Two (trigger immediately). Do not enable Condition Three or Four. For aggregation mode, it is not recommended to use latency-based conditions for disablement decisions.)
Condition
Parameter
Game (Multi-Send Selective-Receive)
TRTC
Condition 1
Wait duration
10 seconds
10 seconds
Condition 2
(Immediate trigger)
-
-
Condition 3
Quality evaluation window
300 seconds
300 seconds
 
Latency ratio / Jitter ratio
100% / 80%
100% / 80%
Condition 4
Measurement window
Disabled
10 seconds
IV. API Settings
1. Probe Startup Policy
The network measurement configuration object. By configuring this parameter, you can achieve dynamic acceleration performance.
1.1 Android SDK
API
Description
setRTT
Set latency threshold
setLoss
Set packet loss rate threshold
setJitter
Set jitter threshold
setTime
Set sliding window measurement time
setRTT
Set the latency threshold. When the actual network latency of the terminal within the sliding window exceeds the set latency threshold, the onStartMpAcc API is called back.
public MeasureConfig setRTT(int RTT)
Parameter description:
Parameter
Type
Description
RTT
int
Latency threshold (ms)
setLoss
Set the packet loss rate threshold. When the actual network packet loss of the terminal within the sliding window exceeds the set packet loss threshold, the onStartMpAcc API is called back.
public MeasureConfig setLoss(int loss)
Parameter description:
Parameter
Type
Description
loss
int
Packet loss percentage threshold (0-100)
setJitter
Set the jitter threshold. When the actual network jitter of the terminal within the sliding window exceeds the set jitter threshold, the onStartMpAcc API is called back.
public MeasureConfig setJitter(int jitter)
Parameter description:
Parameter
Type
Description
jitter
int
Network jitter threshold (ms)
setTime
Set the sliding window measurement time.
public MeasureConfig setTime(int time)
Parameter description:
Parameter
Type
Description
time
int
Measurement duration, unit: ms
1.2 iOS SDK
Required
Description
time
Sliding window measurement time, unit: ms
rtt
Latency threshold, unit: ms
loss
Packet loss percentage threshold (0-100)
jitter
Jitter threshold, unit: ms
2. Quick Startup Policy
Enable fast start by configuring the fast start window time and fast start latency threshold.
2.1 Android SDK
API
Description
setQuickTime
Set quick start window time
setQuickRtt
Set quick start latency threshold
setQuickRtt
Set the fast start latency threshold. This interface is designed for scenarios with a sharp latency increase. When the actual network latency of the terminal within the fast start window exceeds the set fast start latency threshold, the onStartMpAcc API is called back.
public MeasureConfig setQuickRtt(int quickRtt)
Parameter description:
Parameter
Type
Description
quickRtt
int
Fast startup latency threshold, unit: ms
setQuickTime
Set the fast start window measurement time.
public MeasureConfig setQuickTime(int quickTime)
Parameter description:
Parameter
Type
Description
quickTime
int
Fast startup window time, unit: ms
2.2 iOS SDK
Required
Description
quickTime
Fast startup window time, unit: ms
quickRtt
Fast startup latency threshold, unit: ms
3. Dynamic Fallback-to-Origin Policy
For the fallback-to-origin custom object, if the business does not set AdditionalOptions, the SDK adopts the default fallback logic (triggering onAccException). If the business has set AdditionalOptions, the SDK's fallback logic follows the business configuration.
3.1 Android SDK
API
Description
PacketLossEscape
Triggered when the acceleration link is disconnected for [packetLossCount] consecutive times.
MaxRttEscape
Triggered when the ping value of the acceleration link is greater than or equal to [rttThreshold] ms for [maxRttCount] consecutive times.
RttExceptionEscape
Triggered when the average ping value of the acceleration link over [detectWindowTime] ms is greater than that of the primary link by [rttDiffThreshold]%, and the average latency of the acceleration link is greater than [accBenchmarkRtt] ms.
StopAccRemind
It is recommended to disable acceleration (which triggers onStopMpAcc) when the average latency of the acceleration link within [detectWindowTime] ms is greater than that of the primary link by [rttDiffThreshold]%, and the jitter is greater than that of the primary link by [jitterDiffThreshold]%.
setAdditionalOptions
Set custom options for fallback-to-origin escape.
setAdditionalOptions
Set the fallback-to-origin custom options.
public MeasureConfig setAdditionalOptions(AdditionalOptions additionalOptions) 
3.2 iOS SDK
Required
Description
packetLossEscape
Triggered when the acceleration link is disconnected for [packetLossCount] consecutive times.
maxRttEscape
Triggered when the ping value of the acceleration link is greater than or equal to [rttThreshold] ms for [maxRttCount] consecutive times.
rttExceptionEscape
Triggered when the average ping value of the acceleration link over [detectWindowTime] ms is greater than that of the primary link by [rttDiffThreshold]%, and the average latency of the acceleration link is greater than [accBenchmarkRtt] ms.
stopAccRemind
It is recommended to disable acceleration (which triggers onStopMpAcc) when the average latency of the acceleration link within [detectWindowTime] ms is greater than that of the primary link by [rttDiffRate]%, and the jitter is greater than that of the primary link by [jitterRate]%.
additionalOptions
Set custom options for fallback-to-origin escape.
4. Recommended Disable Policy
This policy generally does not require configuration changes and uses the default value. If modifications are needed, make them in StopAccRemind.
4.1 Android SDK
API
Description
StopAccRemind
It is recommended to disable acceleration (which triggers onStopMpAcc) when the average latency of the acceleration link within [detectWindowTime] ms is greater than that of the primary link by [rttDiffThreshold]%, and the jitter is greater than that of the primary link by [jitterDiffThreshold]%.
setDisableSlaveLossDetect
Disable packet loss detection on the secondary link.
setDisableSlaveLossDetect
Disable secondary path detection. For fast switching mode, it is not disabled by default. If 100% packet loss occurs on the secondary path latency within the measurement window, the onStopMpAcc API is called back to recommend disabling acceleration.
public MeasureConfig setDisableSlaveLossDetect(boolean disableSlaveLossDetect)
Parameter description:
Parameter
Type
Description
disableSlaveLossDetect
boolean
true: Disabled  
false: Not disabled
4.2 iOS SDK
Required
Description
stopAccRemind
It is recommended to disable acceleration (which triggers onStopMpAcc) when the average latency of the acceleration link within [detectWindowTime] ms is greater than that of the primary link by [rttDiffRate]%, and the jitter is greater than that of the primary link by [jitterRate]%.
disableSlaveLossDetect
Disable packet loss detection on the secondary link.
true: Disabled 
false: Not disabled
V. Sample Code
For details, see Dynamic Acceleration.
﻿

Help and Support

Was this page helpful?

You can also Contact sales or Submit a Ticket for help.

Help us improve! Rate your documentation experience in 5 mins.

Feedback

tencent cloud

Multiple Network Acceleration

Dynamic Acceleration Configuration Reference

I. Overview

II. Core Concepts

1. Three Key Dimensions

2. Recommended Pairings of Scenarios and Modes

III. Policy Details

1. Probe Startup Policy

2. Quick Startup Policy

3. Dynamic Fallback-to-Origin Policy

4. Recommended Disable Policy

IV. API Settings

1. Probe Startup Policy

1.1 Android SDK

setRTT

setLoss

setJitter

setTime

1.2 iOS SDK

2. Quick Startup Policy

2.1 Android SDK

setQuickRtt

setQuickTime

2.2 iOS SDK

3. Dynamic Fallback-to-Origin Policy

3.1 Android SDK

setAdditionalOptions

3.2 iOS SDK

4. Recommended Disable Policy

4.1 Android SDK

setDisableSlaveLossDetect

4.2 iOS SDK

V. Sample Code

Help and Support

Scenario	Recommended Mode	Reason	Typical Customer
Games (FPS/MOBA)	Multi-Send and Selective Receive (Dual-Send)	Small packet traffic, pursuing extremely low latency	Mobile MOBA Games
Real-time audio and video communication	Real-time mode (RTC)	Audio and video streams have high requirements for continuity.	Audio Call Video Conference
Live streaming	Aggregation mode	High bandwidth requirement, aggregating multiple channels	Gaming Outdoor Live Streaming

Policy	Problem to Solve	Post-Trigger Action
Probe Startup Policy	Network performance continues to degrade, requiring acceleration to be enabled.	After the client is called back, the decision is made by the customer.
Quick Startup Policy	Network performance deteriorates abruptly, requiring immediate acceleration.	After the client is called back, the decision is made by the customer.
Dynamic Fallback-to-Origin Policy	The acceleration link performs worse than the direct connection.	The SDK automatically falls back to a direct connection.
Recommended Disable Policy	Network recovers, and acceleration is no longer necessary.	After the client is called back, the decision is made by the customer.

Parameter	Meaning	Gaming Scenarios	Real-time audio and video communication	Streaming Scenarios
Time window	Observation time window	8s	8s	Enable at all times (no configuration required).
Latency threshold	Triggers when average latency exceeds this threshold.	60ms	80ms	-
Jitter threshold	Triggers when latency jitter exceeds this threshold.	15ms	20ms	-
Packet loss threshold	Triggers when packet loss rate exceeds this threshold.	5%	5%	-

Compare	Probe Initiation	Fast Startup
Window / Metric	8s / latency + jitter + packet loss	2s / latency only
Trigger Threshold	Lower (sensitive)	Higher (to prevent false triggers)
Positioning	Detect a continuously deteriorating trend.	Detect sudden performance degradation events.

Condition	Judgment Rule	Plain Meaning
Condition 1: Complete Disconnection	Triggered when consecutive packet loss on the acceleration link reaches the [consecutive packet loss count] threshold, and the primary link is not simultaneously disconnected.	The acceleration link is down, but the direct connection is still up. Fallback should be performed immediately.
Condition 2: Extremely High Latency	Triggered when the latency of [consecutive high-latency packet count] consecutive packets on the acceleration link is ≥ [single-packet latency upper limit] ms.	The link is not down, but the latency is already too high to be acceptable.
Condition 3: Persistently Worse Than Direct Connection	Triggered when, within the [evaluation window], the average acceleration latency is greater than the primary link latency multiplied by [latency ratio threshold]%, and the average acceleration latency is greater than [minimum latency threshold] ms.	Long-term observation shows that using the acceleration link is worse than using the direct connection, and the latency is indeed not low.

Condition	Parameter	Game (Multi-Send Selective-Receive)	TRTC
Condition 1	Consecutive packet loss quantity	4 packets	4 packets
Condition 2	Consecutive high-latency packet quantity	4 packets	Disabled
Condition 2		Maximum single-packet latency	400ms	-
Condition 3	Evaluation window duration	60 seconds	60 seconds
		Latency ratio threshold	110%	110%
		Minimum latency threshold	66ms	66ms
Streaming/aggregation mode	Enable only Condition 1 (number of consecutive packet losses = 4), and disable Condition 2 and Condition 3.

API	Description
setRTT	Set latency threshold
setLoss	Set packet loss rate threshold
setJitter	Set jitter threshold
setTime	Set sliding window measurement time

Parameter	Type	Description
loss	int	Packet loss percentage threshold (0-100)

Required	Description
time	Sliding window measurement time, unit: ms
rtt	Latency threshold, unit: ms
loss	Packet loss percentage threshold (0-100)
jitter	Jitter threshold, unit: ms

API	Description
setQuickTime	Set quick start window time
setQuickRtt	Set quick start latency threshold

Required	Description
quickTime	Fast startup window time, unit: ms
quickRtt	Fast startup latency threshold, unit: ms

API	Description
PacketLossEscape	Triggered when the acceleration link is disconnected for [packetLossCount] consecutive times.
MaxRttEscape	Triggered when the ping value of the acceleration link is greater than or equal to [rttThreshold] ms for [maxRttCount] consecutive times.
RttExceptionEscape	Triggered when the average ping value of the acceleration link over [detectWindowTime] ms is greater than that of the primary link by [rttDiffThreshold]%, and the average latency of the acceleration link is greater than [accBenchmarkRtt] ms.
StopAccRemind	It is recommended to disable acceleration (which triggers onStopMpAcc) when the average latency of the acceleration link within [detectWindowTime] ms is greater than that of the primary link by [rttDiffThreshold]%, and the jitter is greater than that of the primary link by [jitterDiffThreshold]%.
setAdditionalOptions	Set custom options for fallback-to-origin escape.