Traffic Forecasting ist im Telco- und Provider-Design die Disziplin, aus Messdaten belastbare Aussagen über zukünftige Last zu machen – inklusive Saisonalität, Peaks und dem gezielten Event-Handling. Wer nur lineare Trends betrachtet („+x% pro Monat“), wird in der Praxis überrascht: Abendspitzen verlagern sich, ein neues Content-Release erzeugt kurzfristig extreme Downloadwellen, Sportevents treiben Live-Streaming, regionale Ausbaugebiete wachsen sprunghaft, und ein IXP-Fabric-Problem kann Traffic plötzlich auf Transit kippen. Das Ergebnis sind klassische Kapazitätsincidents: Links sind im Tagesmittel entspannt, aber p99-Latenz steigt; Queues droppen in Peak-Minuten; CGNAT, Firewalls oder Logging-Pipelines laufen in CPS/State-Limits; und im N-1-Fall reichen Reserven nicht. Professionelles Forecasting ist deshalb topologisch: Es betrachtet nicht „das Netz“, sondern Linkklassen und Servicepfade (Access, Metro, Core, Edge/Interconnect, Service Chains). Es arbeitet mit mehreren Zeitskalen (Minuten, Stunden, Tage, Wochen), nutzt robuste Kennzahlen (p95/p99, Peak-Minuten, Microburst-Indikatoren), und übersetzt Vorhersagen in konkrete Design- und Betriebsentscheidungen: Headroom-Regeln, Upgrade-Trigger, Event-Playbooks, Traffic Engineering und SLO-Guardrails. Dieser Artikel zeigt, wie Sie Saisonalität und Peaks modellieren, wie Sie Events vorab planen und wie Sie Forecasting so in das Netzdesign integrieren, dass Wachstum kontrolliert bleibt – ohne Krisen-Upgrades und ohne ständigen Alarmmodus.
Warum Traffic Forecasting im Provider-Netz anders ist als „Trendlinie ziehen“
Traffic wächst nicht nur, er verändert sich. Der Mix (Video, Gaming, Cloud, Updates), die Richtung (Inbound/Outbound), die Orte (Regionen/PoPs) und die Pfade (PNI/IXP/Transit) verschieben sich ständig. Zusätzlich sind Telco-Netze redundant: Im Störfall ändern sich Pfade, und damit ändern sich Engpassstellen. Ein Forecast, der nur auf Gesamttraffic basiert, ist deshalb für Designentscheidungen oft zu grob.
- Mehrdimensionale Last: Throughput, PPS, CPS, State, Queue-Drops und Telemetry/Logging-Last wachsen unterschiedlich.
- Topologische Verschiebungen: Neue Peers/PNIs, Exit-Regionalisierung und TE verändern, wo Traffic landet.
- Zeitskalen: Langfristiger Trend (Monate) und kurzfristige Peaks (Minuten) sind beide relevant.
- N-1 Realität: Forecast muss Failoverpfade und Störfalllast berücksichtigen, nicht nur Normalbetrieb.
Leitprinzip: Forecasts müssen eine Designentscheidung beantworten
Gute Forecasts sind nicht „schöne Grafiken“, sondern Entscheidungsvorlagen: Wann ist ein Port upgradefällig? Welche Region braucht einen zusätzlichen Hub? Reicht N-1 Headroom in Peakzeiten? Welche Event-Runbooks müssen aktiviert werden?
Die vier Muster von Traffic: Trend, Saison, Peak und Shift
Für praktische Forecasts hilft eine einfache Zerlegung: (1) langfristiger Trend, (2) saisonale Muster, (3) Peaks/Extremwerte und (4) Shifts durch externe Veränderungen. Diese vier Muster sollten Sie getrennt betrachten, weil sie unterschiedliche Maßnahmen auslösen.
- Trend: Langfristiges Wachstum durch Kundenzuwachs, höhere Bitraten, mehr Devices.
- Saisonalität: Wiederkehrende Muster (Tagesgang, Wochentage, Ferien, Jahreszeiten).
- Peaks: Kurzzeitige Extreme (Microbursts, Release-Tage, Live-Events), oft maßgeblich für QoS und SLOs.
- Shifts: Strukturbrüche durch Peering-Änderungen, neue CDNs, neue Produkte, regionale Ausbauwellen.
Ein robustes Modell für den Alltag
Sie müssen diese Bestandteile nicht perfekt mathematisch trennen. Entscheidend ist, dass Sie sie operational getrennt behandeln.
Saisonalität modellieren: Tagesgang, Wochenprofil und „kalte“ vs. „heiße“ Monate
Saisonalität ist im Telco-Betrieb der stärkste wiederkehrende Effekt. Typisch sind Abendspitzen, Wochenendprofile und saisonale Verschiebungen (Ferien, Wintermonate, Feiertage). Für Forecasting bedeutet das: Sie sollten nicht nur „Monatsmittel“ forecasten, sondern die Peak-Fenster pro Tag/Woche – denn diese bestimmen Engpässe, QoS-Drops und Kundenerlebnis.
- Daily Pattern: Morgen/Arbeitszeit vs. Abendspitze; oft unterschiedliche Trafficarten (Business vs. Video).
- Weekly Pattern: Wochenende häufig anders als Werktage; Gaming/Streaming kann stark variieren.
- Seasonal Months: Ferienzeiten verlagern Last, Winter kann Streaming intensivieren, Feiertage erzeugen Event-Peaks.
- Regionale Unterschiede: Saisonalität kann je Region stark abweichen (Tourismusregionen, Uni-Städte, Industriecluster).
Praktische Kennzahl: „Busy Hour“ plus „Busy Minute“
Viele Kapazitätsentscheidungen sollten mindestens zwei Kennzahlen berücksichtigen: die Busy Hour (z. B. höchste Stunde pro Tag) und die Busy Minute (höchste Minute pro Woche). Busy Minute ist häufig näher an der Wahrheit für Queueing und SLO-Spikes.
Peaks verstehen: Microbursts, Heavy Hitters und „Release-Wellen“
Peaks sind nicht nur große Zahlen, sondern Formen. Microbursts (sehr kurz) erzeugen Drops, Heavy Hitters (einige große Flows) erzeugen Hotspots, Release-Wellen (viele neue Verbindungen) belasten CPS/State. Ein gutes Forecasting unterscheidet Peak-Typen, weil die Gegenmaßnahmen unterschiedlich sind.
- Microbursts: Sekunden- oder Subsekunden-Spitzen; relevant für Queue-Drops und p99-Latenz.
- Volume Peaks: Hohe bps über Minuten/Stunden; relevant für Portauslastung und Transitkosten.
- CPS/Session Peaks: Viele neue Verbindungen; relevant für CGNAT, Firewalls, Proxies und BNG-Churn.
- Skew/Imbalance Peaks: ECMP/LAG verteilt ungleich; einzelne Member überlasten trotz freier Gesamtbandbreite.
Designregel: Peaks bestimmen Headroom, nicht der Durchschnitt
Wenn Sie SLOs für Latenz/Loss einhalten wollen, müssen Sie die Peaks modellieren. Durchschnittsauslastung kann „gesund“ aussehen, während die Nutzererfahrung regelmäßig leidet.
Event-Handling im Design: Von „Überraschung“ zu Playbook
Events sind planbar – zumindest in ihrer Existenz. Sie wissen, dass es Sportfinals, große Game-Releases, Streaming-Premieren, Feiertage und regelmäßige Patchdays gibt. Ein professionelles Netzdesign behandelt Events als eigene Lastklasse: Sie definieren Event-Scenarios, messen historische Muster, planen Headroom und erstellen Runbooks, wie die Topologie und Policies im Event-Fall reagieren sollen.
- Event-Kalender: Wiederkehrende Events (Sport, Feiertage, Releases) als Input für Forecasting.
- Event-Profile: Welche Regionen, welche ASNs/Content-Partner, welche Linkklassen werden belastet?
- Event-Headroom: Reserven an Interconnect/Edge und DCI; QoS-Schutz für kritische Klassen.
- Event-Playbooks: Zusätzliche Ports aktivieren, Traffic umsteuern, Sampling erhöhen, Monitoring schärfen.
Ein praktisches Event-Ziel: „Graceful Degradation“
Manche Events übersteigen kurzfristig jede wirtschaftliche Vollauslegung. Dann ist das Ziel: kritische Services stabil halten, Bulk kontrolliert degradieren, und Incidents durch klare Guardrails vermeiden.
Topologisches Forecasting: Forecast pro Linkklasse und Servicepfad
Traffic Forecasting wird erst wirklich nützlich, wenn es topologisch segmentiert ist. Statt „Gesamttraffic +15%“ brauchen Sie Aussagen wie: „IXP Region West p95 steigt 20%, Transit Region Süd bleibt stabil, DCI Regionpaar A-B wächst 10%, CGNAT CPS Peaks steigen 30%“. Diese Segmentierung entspricht der realen Engpasslandschaft.
- Interconnect: PNI/IXP/Transit getrennt forecasten; Traffic-Mix nach ASN/Partner hilft bei Upgrade-Planung.
- Metro/Hubs: Aggregationsuplinks nach Region und Ring/Hub forecasten, inkl. N-1 Szenarien.
- Core/DCI: Regionpaare und TE-Pfade forecasten; Cross-Region-Failover berücksichtigen.
- Service Edges: BNG Sessions/Churn, CGNAT State/CPS, Firewall PPS/Session-Table als eigene Forecast-Dimensionen.
Designregel: Forecasts müssen Label-fähig sein
Ohne konsistente Labels (Region, PoP, Linkklasse, Serviceklasse, Peer/ASN) können Sie Forecasts nicht sinnvoll in Upgrade-Backlogs übersetzen. Datenmodell ist Forecasting-Grundlage.
Forecasting-Methoden im Alltag: Von robust bis anspruchsvoll
Sie brauchen nicht immer komplexe ML-Modelle. In vielen Netzen reichen robuste, erklärbare Verfahren, solange sie Peak- und Saisonlogik enthalten. Entscheidend ist, dass die Methode stabil ist und von Betriebsteams verstanden wird.
- Rolling Baseline: Vergleich mit gleitendem Median/Perzentil der letzten Wochen, gut für Anomalien und Saison.
- Trend + Saison: Separate Betrachtung von Trend (Monate) und Tages-/Wochenprofilen.
- Quantile Forecasting: Direkte Vorhersage von p95/p99 statt Mittelwerten, passend für SLOs.
- Scenario Forecasting: „Was passiert, wenn Transit ausfällt?“ oder „wenn PNI X down ist?“ – besonders wertvoll für Headroom.
Anti-Pattern: Ein Modell für alles
Ein DCI-Link verhält sich anders als ein IXP-Port, ein Access-Uplink anders als CGNAT CPS. Nutzen Sie pro Linkklasse passende Modelle und KPI-Sets.
Headroom für Peaks: N-1, QoS und Portklassen als Werkzeugkasten
Forecasting endet nicht bei Zahlen. Es muss in Headroom-Strategien übersetzt werden: N-1 Reserve, QoS-Klassen, Portklassen an der Edge, und definierte Upgrade-Trigger. Peaks lassen sich oft wirtschaftlicher durch Kombination aus moderatem Headroom und klaren Betriebsmaßnahmen abfangen.
- N-1 Headroom: Kritische Klassen müssen auch im Failover SLO-konform bleiben.
- QoS-Profile: Echtzeit und kritische Dienste schützen; Bulk kontrolliert degradieren.
- Portklassen: Interconnect-Ports mit Zielauslastungen (p95/p99) und Upgrade-Triggern.
- Traffic Steering: Temporäre TE/Policy-Anpassungen bei Events, aber nur mit klaren Guardrails und Rollback.
Ein praktischer Upgrade-Trigger für Peaks
Wenn p99-Auslastung oder Queue-Drops an Engpässen in mehreren Wochen wiederkehrend auftreten, ist das ein stärkeres Signal als „80% Average“. Peaks sind der Design-Driver für Nutzererlebnis.
Event-Runbooks: Was Sie im Design vorab festlegen sollten
Runbooks sind nicht nur Betriebspapiere, sondern Design-Artefakte. Sie definieren, welche Stellschrauben im Eventfall erlaubt sind: zusätzliche Kapazität aktivieren, Peering-Policy anpassen, DDoS-Mitigation vorbereiten, Telemetry-Sampling erhöhen, oder bestimmte Dienste priorisieren. Ein gutes Runbook ist kurz, topologisch strukturiert und mit Messkriterien verknüpft.
- Trigger: Welche KPIs starten den Event-Mode (p95/p99, Drops, Transit-Spike, SLO-Verletzung)?
- Aktionen: Port/Link aktivieren, Traffic umsteuern, QoS-Profile schärfen, Sampling erhöhen.
- Guardrails: Max-Prefix/Policy-Limits, Change-Governance, Hysterese gegen Ping-Pong.
- Exit Criteria: Wann kehren Sie zum Normalbetrieb zurück? Rollback-Kriterien definieren.
Designregel: Event-Handling muss reversibel sein
Temporäre Policy-Änderungen sind riskant, wenn sie „kleben bleiben“. Definieren Sie deshalb klare Exit-Kriterien und automatisierbare Rollbacks.
Observability für Forecasting: Die KPIs, die Sie nicht vergessen dürfen
Traffic Forecasting braucht mehr als bps. Besonders für Peaks und Events benötigen Sie KPIs, die Engpässe sichtbar machen und Ursachen erklären. Ohne diese KPIs werden Forecasts zu reiner Zahlenakrobatik.
- Queue-Drops: Pro Klasse an Engpässen, weil Drops häufig vor „vollen Links“ auftreten.
- Member-Visibility: LAG/ECMP Imbalance, um Hotspots zu erkennen.
- Interconnect Mix: PNI vs. IXP vs. Transit; Transit-Spikes sind oft Incident-Frühindikatoren.
- Service KPIs: CGNAT CPS/State, BNG Churn, Logging/Collector Health – gerade bei Eventwellen.
- Path KPIs: p95/p99 Latenz/Loss zu Referenzzielen; SLO-Impact sichtbar machen.
Evidence-by-Design: Forecasts müssen überprüfbar sein
Jeder Forecast sollte ein Monitoring-Pendant haben: Sie müssen nach dem Event oder nach dem Monat prüfen können, wie gut das Modell war und welche Abweichungen neue Designmaßnahmen erfordern.
Typische Fallstricke und wie man sie vermeidet
- Nur Gesamttraffic forecasten: Lösung: Forecast pro Region/PoP/Linkklasse/Servicekette.
- Durchschnittswerte statt Peaks: Lösung: p95/p99, Busy Minute, Queue-Drops, Microburst-Indikatoren.
- Policy-Shifts ignoriert: Lösung: Peering/Transit/TE-Changes als Szenarien modellieren, Vorher/Nachher messen.
- Keine Event-Playbooks: Lösung: Event-Kalender, Event-Mode Trigger, reversible Aktionen, klare Exit-Kriterien.
- N-1 nicht eingeplant: Lösung: Failure-aware Forecasting und regelmäßige Failover-Tests unter Last.
- Telemetry-Pipeline limitiert: Lösung: Collector-Headroom, Sampling-Strategien, Priorisierung kritischer KPIs.
Praktische Leitlinien: Saisonalität, Peaks und Event-Handling im Design
- Traffic in Muster zerlegen: Trend, Saisonalität, Peaks und Shifts getrennt analysieren und operationalisieren.
- Topologisch forecasten: Pro Region/PoP und Linkklasse (IXP/PNI/Transit/DCI/Hub) statt globaler Zahlen.
- Peak-KPIs verwenden: p95/p99, Busy Minute, Queue-Drops, Member-Imbalance und Path-KPIs als Design-Driver.
- Event-Kalender etablieren: Wiederkehrende Events erfassen, historische Profile ableiten, Event-Headroom planen.
- Event-Playbooks definieren: Trigger, Aktionen, Guardrails und Exit-Kriterien – reversibel und messbar.
- N-1 integrieren: Forecasts für Failoverpfade und Störfalllast; Headroom und QoS im N-1 validieren.
- Interconnect-Mix modellieren: PNI/IXP/Transit-Anteile forecasten und Transit-Spikes als Risikoindikator nutzen.
- Serviceketten einbeziehen: CGNAT/BNG/Firewall/Logging-Last separat forecasten, nicht nur Link-bps.
- Forecasts auditieren: Regelmäßiger Forecast-vs.-Reality Review, Modell- und Trigger-Tuning als Prozess.
