How does PIR (Peak Information Rate) work?

[Mitrixsen]

Hello, everyone.

I am a little confused about what PIR (Peak Information Rate) is. My study resource says that it's the bandwidth that the ISP can offer us if there is no congestion on the network? The context in this case is peak traffic shaping (QoS).

However, congestion where exactly? Inside our network or in the ISP's network? Logically, shouldn't it be the ISP's network? If the ISP isn't congested, we can send data up to the PIR (so more) but if there's congestion, we can only send up to the CIR (less).

Or am I misunderstanding this all? Could someone please explain and clarify this concept for me?

Thank you.
David

[M02@rt37 · Accepted solution]

Hello @Mitrixsen 

First, happy new year 2025 !!!

PIR is the maximum bandwidth that your ISP allows you to use under ideal conditions—essentially, when there is no congestion. It represents a "burst" limit, enabling you to transmit at a higher rate than your CIR temporarily, assuming the network has available capacity.

Now, regarding congestion: your intuition is correct. Congestion in this context refers to the ISP's network. If the ISP’s network is experiencing congestion, they may only guarantee the CIR, which is the baseline bandwidth you are always entitled to receive. The PIR is available only when the ISP's network has sufficient free capacity to handle the burst traffic without impacting other users.

To sum up:

• CIR: The guaranteed minimum bandwidth the ISP commits to delivering, regardless of network conditions.
• PIR: The potential maximum bandwidth you can use, provided the ISP's network is uncongested.

When your network sends data above the CIR and up to the PIR, the ISP marks this extra traffic as "best effort." This traffic might be dropped or delayed if congestion occurs in the ISP's network. This means the actual traffic shaping happens based on the ISP’s network conditions, not your internal network's state.

So, the ability to use PIR depends on congestion in the ISP’s network, not your internal network. If their network is congested, only CIR is assured.

[Mitrixsen]

Thank you for the clarification, happy new year to you as wel!

[Joseph W. Doherty]

BTW, in my experience I haven't encountered a service provider that worked as M02@rt37 describes.  I'm not saying such don't exist, I've just not seen such behavior.

In one my replies I describe the various WAN technologies I've worked with.  Vendors ranged from international tier one vendors to some little local SP in 3rd world.

My last networking position was with a national cable TV provider which was also a rather large SP/ISP in its own right (actually the latter not only a huge part of revenue but very profitable), although I didn't work in that division (although we would sometimes use our own SP/ISP services to support our internal Enterprise network [about 5,000 network devices supporting about 100,000 employees]).

However, I retired about 6 years ago, and it's also possible SPs do things differently then they did years ago 

[M02@rt37]

Historically, many ISPs have prioritized simplicity in their service models, especially when catering to enterprise customers. Offering CIR as a strict guarantee and often avoiding complex PIR-based policies was common practice, especially in traditional WAN technologies like Frame Relay, ATM, or basic MPLS. These technologies often revolved around guaranteed bandwidth commitments rather than burstable rates, making PIR less relevant in those contexts.

Industry has evolved in the last six years, especially with the proliferation of cloud-native networks, SD-WAN, and hyper-scaler infrastructures. Many ISPs now optimize unused capacity dynamically, and PIR concepts are more commonly seen in consumer-grade broadband or flexible business plans, though the implementation still depends on the provider.

[Joseph W. Doherty]

---

M02@rt37 wrote:

Industry has evolved in the last six years, especially with the proliferation of cloud-native networks, SD-WAN, and hyper-scaler infrastructures. Many ISPs now optimize unused capacity dynamically, and PIR concepts are more commonly seen in consumer-grade broadband or flexible business plans, though the implementation still depends on the provider.

---

No doubt there's been evolution in the market regarding usage of PIR, but I would need to see the specs on typical current PIR offerings because being somewhat of a cynic when it comes to most sellers (caveat emptor), I would first expect even current PIR to be just another shade of lipstick on the pig.  ; )

Don't misunderstand that I don't see any use cases where PIR can be useful, just, traditionally, such as special variable bit rate usage cases as compressed audio or most video (of course, the latter are likely even more prevalent then they were 6 years ago).

Also, how PIR is "recharged", impacts its operations.  (I.e. whether it's recharged based on strictly its Tc or whether it gets "credit" for unused bandwidth previous to current Tc.)

[M02@rt37]

Your skepticism regarding PIR is entirely valid, especially given the historical practices of ISPs and the variability in how features like PIR are marketed and implemented.

Many providers have been known to dress up basic features with attractive terms to appear more customer-centric, while the underlying mechanics may offer limited practical value. Caveat emptor, indeed!

PIR can certainly be useful in specific scenarios, as you noted, particularly with applications like compressed audio, video, or other traffic types with variable bit rates. These use cases benefit from occasional bursts to maintain quality without needing a constant high-bandwidth guarantee. Modern streaming services and real-time communications, which are now more prevalent than ever, could theoretically make good use of PIR, provided the ISP implements it meaningfully.

The operational impact of PIR depends significantly on how its "bucket" is recharged. If the PIR bucket is strictly recharged per time intervale, this creates a rigid framework that may limit its utility in scenarios requiring rapid bursts after longer periods of low usage. However, if the ISP allows the bucket to accumulate "credits" for unused bandwidth from prior intervals, this more flexible approach enables customers to build up capacity for larger bursts. Unfortunately, ISPs don’t always clearly document these nuances, and their policies often vary widely...

Your concerns about how PIR function operationally are especially important ; right. Without clear transparency from the ISP on how the bucket replenishes and whether credits carry over, customers are left guessing about how much bandwidth they can truly access during peak usage. This ambiguity can make PIR seem more like a marketing gimmick than a genuinely valuable feature, depending on the provider's implementation.

In essence, while the concept of PIR has potential and can align well with evolving traffic demands, its value lies in the details of implementation—and those details are where ISPs historically have fallen short. 

[Joseph W. Doherty]

Nice reply!

BTW, years ago, I often found it surprisingly difficult, when a SP had a logical bandwidth cap, to even obtain its Tc/Bc(Be) so I knew what to shape for.

[Joseph W. Doherty · Accepted solution]

Alice, without going down the (rather deep) rabbit hole, with service providers, for CIR or PIR, if you adhere to them you're "guaranteed" to receive them, and when you don't obtain the guaranteed service the service provider should provide some relief, usually monetary.

If you don't adhere to the service terms, what happens depends on the policy of the service provider, which usually is either all excess is immediately dropped or excess is allowed if it's available.

The "if available" usually depends on whether there's congestion within the provider's network, which may also depend on degree of such congestion.

BTW, in many cases, PIR is a joke, but those are down the rabbit hole.

[Mitrixsen]

Thank you for the response.

When it comes to exceeding the CIR, if we're still within the PIR range, the ISP could have a policer configured that could also remark the traffic instead of dropping it, correct? Which would mean that it would be treated as best-effort (which I suppose could work in scenarios like MPLS?)

Thank you for the response.

[Joseph W. Doherty]

If there's a PIR, and traffic is within its spec, why mark it?  Basically, for any out of contract traffic, normally such traffic will be immediately dropped or tagged as a candidate to be later dropped first.

Generally, service providers don't have BE vs. non-BE, or support any kind of prioritization.  Their business is about selling bandwidth.

(I know often "MPLS" service providers provide QoS, but that's also goes down the rabbit hole.)

Various QoS methods manage bandwidth which permit better sharing of bandwidth, but service providers would rather sell you more bandwidth, either in aggregate, or dedicated for specific purposes (actually similar to what hardware vendors do too).

BTW I've provided WAN QoS across P2P least lines, frame-relay, ATM, MetroE, Internet and VPN running on a provider's MPLS.  Of those, the last, VPN/MPLS, which provided some basic QoS, was the one which I couldn't guarantee predictable results.  A fact of which I warned the network manager, and which showed itself, one day about a year later.

Also BTW, don't recall a service provider ever marking my frames or packets (I would have been very POed, if what far side received was changed).  However, what SP did transparently, I didn't care, nor could normally even detect.  (For example, setting FR discard eligible bit, ATM cell CLP bit, q-in-q tag, MPLS EXP bits).

Lastly, my concern is the rabbit hole you're about to fall into won't help you in your studies for passing a QoS exam; often understanding how a policer or shaper work can be confusing enough (as possibly shown by if you think CIR or PIR are "rate" limits).  However, in the real world, there can be much benefit in understanding what a SP is selling (laugh, which often their sales engineers or even first couple level of support engineers do not).