How does SD-WAN application-aware routing keep a store's voice calls on a path that meets their SLA, and what happens when that path degrades?

seniormust knowfreq 28%

answer

classify, measure, compare, steer
probes inside every tunnel
loss, latency and jitter thresholds
brownout is not a dead link
windows and hold-down against flapping

basics

~20 s

Edges probe every tunnel for loss, latency and jitter, compare the results with each application's SLA thresholds, and send voice only over compliant paths; when a path breaches, new flows, and often existing ones, move to another compliant path.

solid answer

~50 s

The edge first classifies traffic into applications, using DSCP, addresses and ports or signature matching. It measures every tunnel continuously with probes sent inside the tunnel, computing loss, latency and jitter over a sliding window. Each application has an SLA class: operator-chosen thresholds such as voice tolerating at most 1 % loss, 150 ms latency and 30 ms jitter. Among the tunnels that meet every threshold, the edge picks by preference or shares load; when the current path breaches any threshold, it steers voice to a compliant path, and when none complies it falls back to the best available one or a designated fallback. The point is the brownout: a broadband tunnel losing 3 % of packets stays up as far as any liveness check is concerned, so only quality measurement moves the calls. Averaging windows and hold-down timers stop calls flapping between two marginal paths.

The edge first **classifies** traffic into applications, using DSCP, addresses and ports or signature matching. It **measures** every tunnel continuously with probes sent inside the tunnel, computing loss, latency and jitter over a sliding window. Each application has an **SLA class**: operator-chosen thresholds such as voice tolerating at most 1 % loss, 150 ms latency and 30 ms jitter. Among the tunnels that meet every threshold, the edge picks by preference or shares load; when the current path breaches any threshold, it steers voice to a compliant path, and when none complies it falls back to the best available one or a designated fallback. The point is the **brownout**: a broadband tunnel losing 3 % of packets stays up as far as any liveness check is concerned, so only quality measurement moves the calls. Averaging windows and hold-down timers stop calls flapping between two marginal paths.

code

pseudocode · 10 lines

pseudocode

for each tunnel t:
    m = window_average(probes(t))        # loss, latency, jitter
    compliant[t] = m.loss <= sla.loss and m.latency <= sla.latency and m.jitter <= sla.jitter

candidates = [t in preference_order if compliant[t] and not in_hold_down(t)]
if candidates is not empty:
    path = candidates[0]
else:
    path = best_available(tunnels) or sla.fallback_path
steer(new_flows_of(app), path)

go deeper

for a junior

Recall the three measured metrics, loss, latency and jitter, and that each application gets its own thresholds that decide which path it may use.

for a middle

Explain classify, measure, compare and steer, and why a path must meet every threshold, not just the one that looks best.

for a senior

Show why brownouts defeat liveness checks, how windows and hold-down prevent flapping, and what duplication or error correction cost when no path complies.

for a principal

Argue how tight thresholds should be: aggressive steering protects calls but burns LTE and destabilises paths, while loose thresholds leave users on a degraded link.

Why liveness is not enough

A routing protocol or a liveness check such as BFD (RFC 5880, which can run over tunnels) answers one question: is the path up? A store's broadband tunnel can be up and still useless for voice. Suppose it randomly loses 3 % of packets. A liveness check that declares a path down after three consecutive missed packets almost never fires: the chance of three losses in a row is 0.03 x 0.03 x 0.03 = 0.000027. Meanwhile every call on that tunnel is audibly broken. This state, up but degraded, is a brownout, and it is the case application-aware routing exists for.

No IETF standard defines SD-WAN or its path-selection algorithm; the mechanism below is the shared architecture, and every threshold in it is an operator's choice.

The four steps

Classify. The edge maps each flow to an application or class: by DSCP marking, by addresses and ports, or by signature matching on the first packets. Signature matching may need several packets before it is sure, so the first packets of a flow can take a default path.
Measure. The edge sends probes inside every tunnel at a fixed interval and computes loss (the share of probes lost), latency (usually round-trip, sometimes one-way, an implementation choice) and jitter (the variation in delay between successive probes) over a sliding window.
Compare. Each application class has an SLA class, a set of thresholds. A path complies only if it meets every threshold in the set.
Steer. Among compliant paths, the edge picks the preferred one, often the cheapest, or spreads flows across them. A breach moves new flows, and often existing ones, to another compliant path.

A worked decision

Voice SLA class, chosen by the operator: loss at most 1 %, latency at most 150 ms, jitter at most 30 ms. (The 150 ms figure echoes the ITU-T G.114 one-way guidance for voice, which is not an IETF text; RFC 4594 only describes telephony as having very low tolerance for loss, delay and jitter.) Preference order: broadband, then MPLS, then LTE.

Tunnel	Loss	Latency	Jitter	Meets voice SLA?
Broadband	2.5 %	35 ms	25 ms	No: loss breaches
MPLS	0.1 %	40 ms	4 ms	Yes
LTE	0.5 %	90 ms	28 ms	Yes

Broadband is preferred but fails the loss threshold, even though its latency is the best of the three. The edge steers voice to MPLS, the next compliant path in preference order. If MPLS also failed, LTE would carry the calls, and if nothing complied the edge would fall back to the best available path or a designated fallback rather than drop the calls.

Keeping the decision stable

Measurement and steering create their own failure mode: two marginal paths and a jumpy policy make calls flap from one to the other.

Averaging windows smooth single bad samples, at the cost of reacting seconds later rather than at once.
Hold-down or restore timers keep a path that just recovered out of use until it has stayed healthy for a while.
Per-flow stickiness keeps one call on one path while it complies, avoiding reordering inside the call.
Hysteresis between the threshold that removes a path and the one that readmits it stops oscillation at the boundary.

When no path is good enough

Steering chooses the best path; it cannot repair one. When every transport is marginal, implementations offer features with a bandwidth price:

Packet duplication sends each voice packet over two transports and discards the later copy, so loss only hurts when both paths drop the same packet.
Forward error correction adds parity packets from which a lost packet can be rebuilt.
Queueing and shaping at the edge protect voice on the store's own uplink, though markings carry no guarantee once the packet enters the internet.

What to say in an interview

Separate liveness (is it up) from quality (is it good enough for this application).
Name all three metrics and say that one breach is enough.
Say who owns the numbers: the operator sets them, no standard does.
Mention stability, because a policy that flaps is worse than one that is slow.

## Why liveness is not enough A routing protocol or a liveness check such as BFD (RFC 5880, which can run over tunnels) answers one question: is the path up? A store's broadband tunnel can be up and still useless for voice. Suppose it randomly loses 3 % of packets. A liveness check that declares a path down after three consecutive missed packets almost never fires: the chance of three losses in a row is 0.03 x 0.03 x 0.03 = 0.000027. Meanwhile every call on that tunnel is audibly broken. This state, up but degraded, is a **brownout**, and it is the case **application-aware routing** exists for. No IETF standard defines SD-WAN or its path-selection algorithm; the mechanism below is the shared architecture, and every threshold in it is an operator's choice. ## The four steps 1. **Classify.** The edge maps each flow to an application or class: by DSCP marking, by addresses and ports, or by signature matching on the first packets. Signature matching may need several packets before it is sure, so the first packets of a flow can take a default path. 2. **Measure.** The edge sends probes inside every tunnel at a fixed interval and computes **loss** (the share of probes lost), **latency** (usually round-trip, sometimes one-way, an implementation choice) and **jitter** (the variation in delay between successive probes) over a sliding window. 3. **Compare.** Each application class has an **SLA class**, a set of thresholds. A path complies only if it meets every threshold in the set. 4. **Steer.** Among compliant paths, the edge picks the preferred one, often the cheapest, or spreads flows across them. A breach moves new flows, and often existing ones, to another compliant path. ## A worked decision Voice SLA class, chosen by the operator: loss at most 1 %, latency at most 150 ms, jitter at most 30 ms. (The 150 ms figure echoes the ITU-T G.114 one-way guidance for voice, which is not an IETF text; RFC 4594 only describes telephony as having very low tolerance for loss, delay and jitter.) Preference order: broadband, then MPLS, then LTE. | Tunnel | Loss | Latency | Jitter | Meets voice SLA? | |---|---|---|---|---| | Broadband | 2.5 % | 35 ms | 25 ms | No: loss breaches | | MPLS | 0.1 % | 40 ms | 4 ms | Yes | | LTE | 0.5 % | 90 ms | 28 ms | Yes | Broadband is preferred but fails the loss threshold, even though its latency is the best of the three. The edge steers voice to MPLS, the next compliant path in preference order. If MPLS also failed, LTE would carry the calls, and if nothing complied the edge would fall back to the best available path or a designated fallback rather than drop the calls. ## Keeping the decision stable Measurement and steering create their own failure mode: two marginal paths and a jumpy policy make calls flap from one to the other. - **Averaging windows** smooth single bad samples, at the cost of reacting seconds later rather than at once. - **Hold-down or restore timers** keep a path that just recovered out of use until it has stayed healthy for a while. - **Per-flow stickiness** keeps one call on one path while it complies, avoiding reordering inside the call. - **Hysteresis** between the threshold that removes a path and the one that readmits it stops oscillation at the boundary. ## When no path is good enough Steering chooses the best path; it cannot repair one. When every transport is marginal, implementations offer features with a bandwidth price: - **Packet duplication** sends each voice packet over two transports and discards the later copy, so loss only hurts when both paths drop the same packet. - **Forward error correction** adds parity packets from which a lost packet can be rebuilt. - **Queueing and shaping** at the edge protect voice on the store's own uplink, though markings carry no guarantee once the packet enters the internet. ## What to say in an interview - Separate **liveness** (is it up) from **quality** (is it good enough for this application). - Name all three metrics and say that one breach is enough. - Say who owns the numbers: the operator sets them, no standard does. - Mention stability, because a policy that flaps is worse than one that is slow.

Why does a liveness check over a tunnel usually miss a 3 % random-loss brownout?
A liveness check declares a path down only after several consecutive probes go missing. With independent 3 % loss, three in a row happen with probability 0.03 cubed, about 0.000027, so the tunnel stays up while voice on it breaks. Quality thresholds measured over a window catch what liveness cannot.
Why not move every flow the instant a single probe breaches the SLA?
Single samples are noisy, so instant reaction makes calls flap between marginal paths, and every move risks reordering and a brief gap. Windows, hold-down timers and hysteresis trade a few seconds of reaction time for a stable decision.
What does packet duplication buy a voice call, and what does it cost?
Each packet goes over two transports and the receiving edge keeps the first copy, so a packet is lost only when both paths drop it. The cost is double the voice bandwidth on the store's uplinks, which matters on metered LTE.

saying these in an interview costs you the question

If the tunnel is still up, the path is fine for voice
A path with the lowest latency always meets a voice SLA
SLA thresholds for SD-WAN are fixed by an IETF standard
Reacting to every single bad probe gives the best voice quality
Steering can make a degraded path good enough for voice

How does SD-WAN application-aware routing keep a store's voice calls on a path that meets their SLA, and what happens when that path degrades?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Why liveness is not enough

The four steps

A worked decision

Keeping the decision stable

When no path is good enough

What to say in an interview

▾common follow-ups3 questions

▾red flags5 flags

Why liveness is not enough

The four steps

A worked decision

Keeping the decision stable

When no path is good enough

What to say in an interview

answer

go deeper