NetAI Blog

Executive summary:

Intermittent performance issues are the hardest incidents to resolve because they rarely trigger a single decisive alarm. Instead, they show up as user complaints, jitter, retransmits, and an SLA trend line that slowly moves toward breach.

This scenario compares two AIOps approaches:

• LLM-based AIOps: strong at summarizing tickets and interpreting text, but weak at locating a deterministic network choke point.
• GNN-based AIOps: topology-aware reasoning on a dependency graph, designed to detect subtle correlated patterns and map them to a specific edge, interface, or queue.

The operational outcome is a large MTTR gap: LLM 1 to 3 days vs GNN 30 to 90 minutes.

The incident pattern: silent degradation in an enterprise WAN

Network context: Enterprise WAN with SD-WAN.
Trigger: Intermittent microbursts due to QoS misconfiguration.
Symptoms: Jitter, retransmits, intermittent user complaints, and SLA trending toward breach.
Hidden cause: Transient drops from a queue/shape mismatch.
Business impact: SLA credits and productivity loss.

Side-by-side timeline: LLM behavior vs GNN behavior

T+0s: Microbursts begin

• Network reality: QoS/queue misconfig causes microbursts; transient drops begin.
• LLM behavior: no action; few or no explicit alarms.
• GNN behavior: detects subtle anomaly pattern across correlated metrics (drops + jitter + retransmits) on a specific edge.
• Outcome: early detection.

T+5m: Users notice intermittently

• Network reality: voice/video jitter increases; users complain.
• LLM behavior: sees scattered complaints/tickets; summarizes intermittent slowness.
• GNN behavior: links user-impact KPIs to dependency paths and identifies a candidate choke point.
• Outcome: connects experience to a network edge.

T+15m: Retransmits rise; latency variance increases

• Network reality: retransmits rise; still no hard-down.
• LLM behavior: suggests generic checks (ISP, bandwidth, reboot).
• GNN behavior: correlates queue depth, drops, and flow behavior; isolates misconfigured QoS queue/interface.
• Outcome: pinpoints exact component.

T+30m: SLA trend line approaches breach

• Network reality: SLA risk becomes measurable.
• LLM behavior: produces narrative risk warning; lacks deterministic where.
• GNN behavior: computes time-to-breach and identifies which services/paths are at risk.
• Outcome: actionable risk quantification.

T+45m: Ad-hoc tests are inconclusive

• Network reality: operators run ping/traceroute; results are noisy.
• LLM behavior: interprets test outputs as text; may overfit to noisy results.
• GNN behavior: uses graph context to interpret tests (which hops matter, which are irrelevant).
• Outcome: avoids false leads.

T+60m: Escalation begins

• Network reality: microbursts continue; more complaints.
• LLM behavior: summarizes escalation thread; still multiple hypotheses.
• GNN behavior: provides a single causal chain: QoS policy mismatch -> transient drops -> jitter -> SLA risk.
• Outcome: faster escalation resolution.

T+75m: Change decision point

• Network reality: engineer considers QoS change but worries about collateral impact.
• LLM behavior: cannot validate change safety; suggests try in maintenance window.
• GNN behavior: performs change impact reasoning on the dependency graph for the specific QoS template adjustment.
• Outcome: safer, faster fix.

T+90m: QoS template corrected

• Network reality: QoS template corrected on the identified interface.
• LLM behavior: notes config change occurred; waits for outcomes.
• GNN behavior: predicts which metrics should normalize first and monitors those edges.
• Outcome: validated remediation.

T+100m: Symptoms resolve

• Network reality: jitter drops; retransmits normalize; complaints stop.
• LLM behavior: summarizes resolved.
• GNN behavior: confirms causal closure: symptom resolution matches predicted propagation order.
• Outcome: high-confidence closure.

T+120m: Prevent recurrence at scale

• Network reality: similar drift could exist elsewhere.
• LLM behavior: suggests standardize QoS configs.
• GNN behavior: identifies other graph edges with the same drift signature and recommends targeted audits.
• Outcome: preventive action at scale.

T+1d: Long tail risk

• Network reality: issue could recur if drift spreads.
• LLM behavior: requires a new incident to learn.
• GNN behavior: continuous detection of the same pattern across the fleet.
• Outcome: sustained advantage.

Why this gap exists: silent degradation is a correlation problem on a graph

This class of incident is not about summarizing alarms. It is about detecting weak signals across correlated metrics, then mapping them to the correct dependency edge.

LLMs can help with communication and summarization. But for deterministic localization and change safety, you need topology-aware reasoning.

What to ask when evaluating AIOps for silent degradation

1. Can it detect correlated weak signals before an SLA breach?
2. Can it map user-impact KPIs to specific dependency paths?
3. Can it isolate the exact queue/interface/template responsible?
4. Can it validate the blast radius of a proposed config change?
5. Can it find the same drift signature elsewhere without waiting for a new incident?

NetAI perspective

NetAI GraphIQ uses GNN-powered, dependency-graph reasoning to turn silent degradation into a deterministic workflow: detect early, localize precisely, validate the fix, and prevent recurrence.