Application Control
End-to-end QoS depends on both network infrastructures (transmission
lines, access lines, traffic engineering policies) and user traffic.
Network bottlenecks result in congestions and may limit optimum
bandwidth to well below its rated value. Transmitting more traffic will only
result in increased transfer time and loss, thereby degrading QoS and application
"goodput".
The goal of the Application Control feature
is to anticipate and avoid congestions, and to guarantee the users'
experience by adjusting each application flow in real-time.
To reach that goal, Application Group attributes include:
|
•
|
the business criticality of the application flow (top, high,
medium or low) |
|
•
|
the bandwidth objective (bandwidth requirements of the application
flow, necessary and sufficient to provide it with good quality) |
|
•
|
the traffic type (real time, transactional or background) |
|
•
|
compression capabilities |
thus allowing the controlling agent to protect the business critical flows dynamically and efficiently,
also taking into account the demand in real time.
Note: There is no need to set low-level network or device-specific
policy rules.
Using these parameters provides the following information:
|
•
|
business criticality: the higher the criticality of the flow,
the more it will be protected |
|
•
|
bandwidth objective: bandwidth that the system will try to
provide to the application flow, even when the available bandwidth is scarce;
the higher the criticality of the flow, the more likely its bandwidth objective
will be met at all times |
|
•
|
traffic type: priorities between the different queues depending
on the sensitivities of the flows to avoid Delay and Jitter, knowing that: |
|
•
|
real time flows are sensitive to Delay and Jitter;
examples: VoIP and Video conference |
|
•
|
transactional flows are sensitive to Delay (but not to Jitter);
examples: Telnet, Citrix |
|
•
|
background flows are not sensitive at all; examples:
file transfer, e-mail |
|
•
|
compression capabilities: to know whether
the flow can be compressed |
Congestion anticipation and avoidance is performed by comparing the
available bandwidth (or network capacity) and the bandwidth used by all the flows
currently running (network usage).
The comparison is performed on the access links, ingress and egress,
and possibly end-to-end (namely if the available bandwidth between any pair
of sites is not fix and guaranteed).
|
•
|
If the network usage reaches about 95% of the network capacity, then Application Control triggers and starts controlling
the bandwidth allocation. |
|
•
|
The network usage is known very precisely, thanks to Application Visibility which measures every
packet crossing the SD-WAN Appliances. |
|
•
|
The network capacity is: |
|
•
|
either fix (and defined in the WAN access parameters), |
|
•
|
or (if it varies) automatically and dynamically estimated
by the Tracking function. |
The Tracking function is activated in the appliance WAN configuration window (see "Configuring the WAN(s)"),
where up and down throughput values are defined for access bandwidth:
If the down throughput is less than the up throughput, then the Tracking function instantaneously estimates the bandwidth,
at any moment, between these two thresholds.
The Tracking function also anticipates and avoids end-to-end
congestions.
Application Control can be summarized as follows:
|
•
|
it globally and dynamically controls bandwidth allocation
between all access points |
|
•
|
it adapts QoS policies to the current network performance and
real user demand |
|
•
|
it selects, for each traffic flow, the right Class of Service
in terms of performance |
based on:
|
•
|
the traffic requirements (criticality, bandwidth objectives) |
|
•
|
the network performance |
