What is Committed Information Rate (CIR)?

Definition: Committed Information Rate (CIR)

Committed Information Rate (CIR) is the minimum guaranteed bandwidth a service provider commits to deliver on a circuit or virtual connection—typically measured in Mbps or Gbps—over a defined time window. Traffic that stays at or below the CIR is treated as “in-profile” and gets forwarding priority under congestion. Traffic above the CIR may be forwarded if capacity exists (often up to a Peak Information Rate, PIR) or may be marked down or dropped according to policy. In short: if you’re searching for “what is Committed Information Rate,” think of CIR as the guaranteed lane on your network highway; anything beyond it rides in the best-effort lane.

Why CIR Matters

Modern networks blend real-time voice/video, SaaS, cloud access, and bulk transfers on the same pipes. Without clear bandwidth guarantees, high-variance bursts can crowd out critical applications and make performance unpredictable. CIR gives you assurance: a deterministic slice of capacity that your business can plan around. Our take? CIR isn’t about buying more megabits—it’s about buying predictability and aligning that guarantee to the applications that actually matter.

Where You’ll Encounter CIR

CIR shows up across multiple access and transport options:

  • Dedicated Internet Access (DIA): The sold rate is effectively your CIR (e.g., 500 Mbps DIA guarantees 500 Mbps).
  • Carrier Ethernet / E-LINE / E-LAN: Providers define CIR (committed) and EIR (excess) per Ethernet Virtual Circuit.
  • Global WAN Services / Private Networking: MPLS and private Ethernet commonly include CIR for each site or class of service.
  • Cloud Connect / Interconnection: Direct cloud on-ramps can be provisioned with CIR for predictable throughput into CSPs.
  • Broadband + SD-WAN: Retail broadband rarely offers CIR; SD-WAN can emulate predictability by steering traffic, but it does not create a true provider-backed CIR.

CIR vs. PIR vs. EIR (Clearing the Terms)

Before diving deeper, it helps to separate three related ideas that providers use in quotes and SLAs.

  • CIR (Committed Information Rate): The guaranteed floor. In-profile traffic is forwarded with SLA backing.
  • PIR (Peak Information Rate): The absolute ceiling the service will ever pass under ideal conditions (not guaranteed).
  • EIR (Excess Information Rate): The “best-effort headroom” above CIR. Traffic in this band is forwarded if capacity exists; under congestion it can be marked down or dropped.

Key point: Only CIR is committed. EIR/PIR are opportunistic.

How CIR Is Enforced (Policing, Shaping, and Bursts)

A short explanation first: networks enforce CIR using rate algorithms that decide which packets are “in profile” and which are not, typically implemented at the edge (customer premises equipment) and provider ingress.

  • Token bucket policing: The service fills a bucket with tokens at the CIR rate. Each packet consumes tokens; if tokens are available, the packet is in-profile. If not, the packet is excess and can be dropped or re-marked (e.g., lower priority).
  • Traffic shaping: Instead of dropping, the edge device buffers packets to smooth bursts down to the CIR over time, reducing loss at the cost of delay.
  • Burst sizes (CBS/EBS): Providers allow limited committed and excess bursts (Committed/Excess Burst Size) so brief spikes can pass without penalty. Choose burst sizes that match your application behavior; too small and legitimate microbursts get punished.

Our take: Shaping at your edge paired with reasonable burst allowances at the provider edge creates the best real-world experience.

How CIR Affects Application Experience

CIR is not just a number on paper; it’s how your apps feel under load:

  • Voice/Video (UCaaS/CCaaS): Guarantee the upstream you truly need; under-allocating CIR causes jitter and choppy calls even if download seems fine.
  • Transactional apps (POS/CRM/ERP): Small, latency-sensitive requests benefit from CIR because queues don’t explode during peaks.
  • Bulk transfers/Backups: These can live in EIR or PIR during off-hours; don’t waste CIR on tasks that can wait.
  • Cloud access: CIR on Cloud Connect keeps east-west traffic predictable, especially for replication and inter-VPC flows.

Sizing CIR (Right-Sizing the Guarantee)

Start with intent, not a speed-test screenshot. A practical approach:

  1. Catalog critical flows. Identify voice/video sessions, POS transactions, API calls, and control-plane traffic that must be steady.
  2. Measure concurrency. Peak simultaneous calls, average bitrate per codec, and overheads (encryption, headers).
  3. Include upstream realities. Many sites are upstream-constrained; CIR must cover the upload that real-time apps need.
  4. Leave a safety margin. Add 15–25% for overhead and microbursts so in-profile traffic stays clean.
  5. Segment by class. If your service supports classes (e.g., real-time vs. best effort), allocate CIR per class aligned to business priority.

Rule of thumb: Buy CIR for what must always work, then let less critical traffic ride EIR or be rate-limited during peaks.

CIR and Classes of Service (CoS/QoS)

CIR becomes more powerful when combined with quality of service:

  • Multiple queues: Assign real-time media to high-priority queues with a portion of CIR reserved.
  • Marking and honoring: Ensure DSCP markings from your LAN are preserved across the WAN; otherwise, your carefully crafted policy is ignored.
  • Admission control: Cap call concurrency to the CIR reserved for voice to avoid self-inflicted congestion.
  • End-to-end alignment: QoS only works when each hop honors it—LAN, SD-WAN edge, underlay, and provider core.

CIR with SD-WAN: Friends, Not Foes

SD-WAN excels at path selection, remediation, and visibility. CIR excels at guaranteed underlay capacity. Together:

  • Use SD-WAN to steer critical traffic onto links where you have CIR and to heal loss with packet replication or FEC.
  • Mix media wisely: Pair a DIA circuit (CIR-backed) with broadband or fixed wireless (no CIR) for cost-effective resilience.
  • Policy by application: Let real-time apps prefer the CIR-backed path; offload bulk or tolerant flows onto best-effort links.

Remember: SD-WAN cannot manufacture a provider guarantee; it can only optimize utilization of what exists.

Reading the Fine Print (SLA Nuances)

Not all “guarantees” are equal. Before you sign:

  • Measurement window: Over what interval is CIR enforced—per second, per 5 minutes? Shorter windows better protect microbursts.
  • Enforcement location: At the provider ingress, egress, or both? Asymmetric policies can surprise you.
  • Remedies: Credits vs. real operational commitments (MTTR, escalation paths).
  • Marking behavior: Is excess traffic dropped or re-marked (e.g., DE, AF classes)? Align with your QoS plan.
  • Burst allowances: Confirm CBS/EBS values; too small and real apps get hurt.
  • Change process: How quickly can you increase CIR during seasonal spikes?

Common Pitfalls (and How to Avoid Them)

Here’s the trap: buying headline bandwidth and assuming it’s all guaranteed. It isn’t—unless the contract says so.

  • Overstuffing the pipe: Running average utilization at 90% leaves no headroom for bursts; CIR becomes a theoretical promise.
  • Ignoring upstream: Many issues are upload-starvation. Allocate CIR where your traffic actually needs it.
  • Mismatched QoS: Marking everything “priority” defeats prioritization. Be selective and verify markings across hops.
  • Tiny bursts: Conservative CBS/EBS can penalize normal application behavior (TLS handshakes, codec spikes).
  • Set-and-forget: Application mixes change. Revisit CIR allocations quarterly with real traffic data.

Practical Example: Branch with UCaaS, SaaS, and POS

A retail branch runs 8 concurrent VoIP calls (≈100 kbps each bidirectional with overhead), POS transactions, and heavy SaaS browsing. The site has 200/50 Mbps DIA. We might reserve 3–5 Mbps of CIR explicitly for voice (including safety margin), 10–15 Mbps for POS/transactional APIs, and leave the rest to best effort. Bursts from software updates move in EIR after hours. SD-WAN steers voice first to the DIA/CIR path; if it degrades, packets replicate over a fixed-wireless link. The result is predictable calls and checkouts—even at peak.

How CIR Connects to Security and Resilience

CIR itself isn’t a security control, but it supports security and continuity goals:

  • SSE/SASE alignment: Stable underlay improves Secure Web Gateway and ZTNA experience, especially for real-time inspection.
  • DDoS Mitigation: CIR-backed DIA often pairs with upstream DDoS protections; ensure mitigation doesn’t starve your CIR class during an attack.
  • Redundancy: Dual circuits with independent providers keep your committed capacity alive during fiber cuts or node failures.

Implementation Roadmap (From Quote to Live)

You don’t need guesswork; you need a plan grounded in data.

  1. Assess demand by class. Use flow records or SD-WAN analytics to quantify real-time, transactional, and bulk.
  2. Model scenarios. Peak periods, maintenance windows, and seasonal spikes—size CIR for the worst hour you must protect.
  3. Negotiate SLA terms. Specify CIR per class, burst sizes, measurement windows, and remedies.
  4. Engineer the edge. Configure shaping, queueing, and marking that mirrors provider classes and CIR allocations.
  5. Test under load. Synthetic voice/video and API tests during business hours validate that in-profile traffic stays clean.
  6. Monitor & iterate. Track jitter/loss for protected classes, call MOS, and transaction latency. Adjust CIR and policies as apps evolve.

The Business Case (Translating CIR to ROI)

Executives don’t buy CIR—they buy outcomes: stable customer experience, reliable operations, and fewer incidents. Tie CIR to:

  • Fewer dropped/poor calls (sales, support).
  • Faster checkouts and transactions (revenue protection).
  • Reduced engineer time on QoS firefighting (Opex).
  • Smoother cloud migrations (project velocity).

When CIR is right-sized and paired with SD-WAN policies, you spend less time chasing brownouts and more time delivering value.

Related Solutions

CIR is most effective as part of a whole-network plan. Dedicated Internet Access (DIA) provides the committed bandwidth foundation for critical sites. SD-WAN turns that capacity into consistent application experience by prioritizing, steering, and healing traffic in real time. For multi-region footprints, Global WAN Services and Interconnection or Cloud Connect extend CIR-backed performance into data centers and cloud providers. Together, these solutions transform CIR from a line item into end-to-end reliability.

FAQs

Frequently Asked Questions

Is CIR the same as my subscribed speed?
Not always. In DIA, yes—your subscribed rate is typically your CIR. In other services, only a portion may be committed, with the rest best effort.
Can I rely on EIR instead of buying more CIR?
For noncritical or off-peak traffic, yes. But during congestion, EIR is the first to suffer. Critical apps should live within CIR.
How do I know if my CIR is too low?
Watch jitter/loss for protected classes, rising queue depths, and call quality degradation at peak. If in-profile traffic struggles, increase CIR or tune QoS.
Does SD-WAN remove the need for CIR?
No. SD-WAN optimizes paths, but it can’t create provider guarantees. Use SD-WAN with CIR for the best results.
What about upstream vs. downstream CIR?
Confirm both. Many issues stem from insufficient upstream commitment for voice, video, and interactive apps.
How often should we revisit CIR settings?
Quarterly is a good cadence—or whenever you add major apps, shift to new codecs, or see persistent peak-hour congestion.
The Next Move Is Yours

Ready to Make Your Next IT Decision the Right One?

Book a Clarity Call today and move forward with clarity, confidence, and control.