Back in July when we introduced our new packages, we described how customers on our new Virtual Interconnect and Managed Interconnect packages (both of whom pay for channels) benefitted from guaranteed capacity and the ability to burst beyond it. This posts seeks to explain that a little more and clear up any confusion we’ve caused!
We’ve said before that due to growth fuelled by a succession of competitor outages, or in some cases instability being the new normal, we need to manage our capacity carefully in order to continue running the network without compromising our standards. We will help with capacity for new and existing customers where we can; but priority is given to those who commit to us rather than those who demand capacity simply because their cheaper/long-standing/locked-in supplier has broken again. Beyond that, priority is given based on commercial sense and those who are paying for channels will come first, those with sensible stable traffic second, and those who want to send traffic once a week only when someone else breaks probably won’t get a look-in.
We’re sorry if this sounds harsh, especially to someone reading this during an outage of their usual provider, but we’re sure you’d do the same. New capacity has already been added and we have massive massive capacity increases (ordered in 2014) coming on-stream soon which will greatly change who we can help. The traffic waiting to come on to the network (of three times current traffic levels) can be fulfilled then. That said, our sales pipeline suggests imminent demand of ten times present levels so this won’t be a silver bullet. Priority based on customer loyalty and commercial reality is therefore here to stay, so it is important we explain clearly how it works.
Developer & Startup accounts
Channel limits are set on accounts as hard values and are distinct for both inbound and outbound call flows. They’re shown in the portal as a solid line and call attempts beyond them will be rejected. Increases can be made upon request, and the above considerations apply. If the limit changes, the line changes as you’d expect. Fulfilment of calls to the level of that limit is on a best efforts basis, and whilst impacted by any capacity impairment, the network is designed in such a way that we have double the capacity on hand to that normally used. This means these channels should be available on a best efforts basis.
Virtual & Managed Interconnect accounts
These customers are committing to a level of capacity and paying for channels. However, in recognition of the redundancy built into our architecture they pay for the same level of capacity for failover, i.e. they’re buying twice as much capacity as they need. We do not want this double capacity to be used routinely and then them find they do not have enough in the hopefully unlikely event of an outage. At the same time though, as they’re paying for it it is wholly unreasonable for us to withhold it!
This is where ‘bursting’ comes in. These accounts have both a soft and hard channel limit; the hard limit being the total amount of channels paid for (including the backup capacity), and the soft limit reflecting what this would be reduced to in the unlikely event of a failure (e.g. relying solely on their backup capacity). Ordinarily the hard limit will be available; the soft limit being priority access and the excess being on a best efforts basis. This gives the capability to burst, but with confidence in availability. In the unlikely event of an outage, the hard limit will reduce potentially as low as the soft-limit.
This will be shown in the portal as two distinct lines, representing the soft and hard limits. Any peaks in traffic that stretch above the soft-limit and into the orange shaded area should be considered “at risk”, i.e. they’re only being completed on a best efforts basis alongside lower commit accounts and the capacity will only be there when we’re running at 100% availability. This is a cue to speak to us and add more channels!
Of course, not every account will have 100% of their channels devoted for outbound use and interconnect customers can tweak the ratio as required. This is done in the portal using the slider shown (Commercial » Account limits or the cog on channel graphs) but can be set instantaneously using the API too. This is, of course, adjusting the soft-limits and the excess burst-ability described above still applies.
Finally, when it comes to rate-limits, these are set to 3 calls per second per notional E1, regardless of commitment level. This is set against the soft-limit and at this level should be more than sufficient for natural traffic. We already limit based on a 10 second average to take account of spikes and in the event of the soft-limit for outbound channels being set below 30 channels, the rate limit will not drop below 3cps.
We hope that helps clarify how this works, and provides a better illustration of the availability of your backup channels. By all means get in touch with us if we can answer any questions.
