[AusNOG] Contention, congestion, and link capacity planning

Tue Sep 19 15:58:36 EST 2017

I personally haven’t done calculations for contention ratios myself, so please forgive me if this is a silly suggestion, but I had a quick tinker and was wondering if calculating the square root of the number of users is a useful factor.

Eg:
sqrt(1) = 1
sqrt(4) = 2
sqrt(10) ~ 3.2
sqrt(50) ~ 7
sqrt(100) = 10

The ratio naturally gets proportionally lower as the number of subscribers goes up. You could have an upper limit that you wouldn’t want to exceed. It would be very easy to drop this into Excel, Javascript, etc.

Of course this doesn’t take into account the individual service speeds, but that would probably only be an issue with a low number of subscribers. Once you have a critical mass of subscribers, just adding up the total aggregate bandwidth sold may be sufficient.

And if you want to adjust the numbers slightly, you can multiply the subscriber number by a suitable amount. These numbers get to what Ahad suggested below, at least for the 5:1 at 10 subscriber mark, but the number for 1 to 5 subscribers probably isn’t helpful. But then you probably don’t need a calculator for that ☺
sqrt(1*2.5) ~ 1.6
sqrt(4*2.5) ~ 3.2
sqrt(10*2.5) = 5
sqrt(50*2.5) ~ 11.2
sqrt(100*2.5) ~ 15.8

I’m sure there are much fancier calculation methods that would scale in a more suitable way, but if all you’re after is a quick and dirty number that has some reasonable consistency, this may be sufficient and won’t hurt your brain when trying to work out what the formula is doing.

From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of paul+ausnog at oxygennetworks.com.au
Sent: Tuesday, 19 September 2017 9:47 AM
To: 'Ahad Aboss' <ahad at swiftelnetworks.com>
Cc: ausnog at lists.ausnog.net
Subject: Re: [AusNOG] Contention, congestion, and link capacity planning

Thanks for all of the on and off list responses, I appreciate everybody’s views and advice.

Unfortunately my picture may not have been painted correctly, but the information I received was greatly appreciated.

The work I am doing is around dimensioning and modelling of backhaul links for sites with a varying amount of business users.
The backhaul then goes to a DC for transit and peering access etc.
Backhauls can be wireless or fibre depending on location and infrastructure available, and costs of course, but I am ultimately trying to get a dynamic equation that can be used to put figures into and gauge the costs at the end.

The general consensus from the information I have received is that a contention ratio of around 5:1 is pretty decent on business grade backhauls, obviously the less users you have the less that should be, so working from 1:1 for a single user site and then ramping up to 5:1 by the time you get 10-15 users at the site seems to be pretty acceptable.

The capacity per user as Ahad has suggested below, and others, works OK once you have the critical mass of users, when working out startup costs of a new site and capacity requirements unfortunately these calculations don’t work, it’s in these situations where I was hoping a silver bullet equation might be around which could help adjust costs and backhaul requirements based on user counts as they ramp up from 1 onwards, or even 5 onwards.
I think now I will just use some basic calculations and create more scenarios rather than have something more dynamic, it’s no issue but I was just hoping I could do it an easier way.

From our historical information and current link capacities we run under that 5:1 figure but pretty close, so using it as a figure for projections should accurately reflect our required bandwidth requirements as well as our current bandwidth allocations which are working comfortably well.

Thanks again

Regards
Paul

From: Ahad Aboss [mailto:ahad at swiftelnetworks.com]
Sent: Monday, 18 September 2017 5:40 PM
To: paul+ausnog at oxygennetworks.com.au
Cc: ausnog at lists.ausnog.net
Subject: Re: [AusNOG] Contention, congestion, and link capacity planning

Hi Paul,

When it comes to backhaul capacity planning for business grade customers, there is no one size fit all formula. It all comes down to the type of customers you have and the frequency of internet usage during business hrs and after hrs.

Generally, the peak usage for business customer is between 8am – 6pm, MON - FRI. You’ll need to have enough backhaul capacity at the head-end to cater for occasional burst during peak hrs though not all customers download at full speed all at once.This is just for safety measures.

For Ethernet or midband Ethernet services through Optus, TPG/AAPT or Telstra, you could get away with 3:1 contention on the backhaul but I strongly recommend that you don’t risk this contention ratio if you have less than 100 customers per state.

Let’s say you have 100 customers, a combination of 50 x 10Mbps and 50 x 20Mbps, you can safely use 1Gbps backhaul per state through a single provider (AAPT/Telstra or Optus) and as you add more customers, you can closely watch the average usage across the customer base and increase the bandwidth as required.

Just to be clear, the 3:1 contention is for best effort Ethernet services ONLY which is mostly used by SMEs, if you are providing guaranteed bandwidth 1:1, you will have to honour the contention all the way to your POP and internet.

If you are building up your customer base slowly, be prepared for very slim or no margins at all as you still need to pay for the access links to customers, trunk port (head end or backhaul), IP transit, rack space, power and cross connect fees.

In these circumstances, it’s best to resell these services through a reliable ISP until your Ethernet customer base is sizeable to justify the head end built.

For residential grade broadband factor in 50% traffic growth every year, a blessing that all ISPs have to deal with while trying to maintain their profit margin. :)

Based on industry contacts, the current average usage per SIO (IN AUS) for NBN and DSL are as follows;

NBN: 1.3Mbps

xDSL: 850Kbps

Netflix and HD/UHD video streaming is changing the peak average rapidly.

I hope this information helps.

Cheers,

Ahad

On Mon, Sep 18, 2017 at 12:41 PM, paul+ausnog at oxygennetworks.com.au<mailto:paul%2Bausnog at oxygennetworks.com.au> <paul+ausnog at oxygennetworks.com.au<mailto:paul+ausnog at oxygennetworks.com.au>> wrote:
Hi All, I was hoping to gain some thoughts from the list around contention and backhaul link capacity planning.

We are working on some new site plans and have plenty of existing sites to draw usage statistics from when it comes to capacity planning, typically all of our backhaul links are running pretty low contention as all of our customers are business customers, but I am wondering if anybody has any formulas they have used successfully in the past.

Being that we only provide business Ethernet connections planning is usually pretty straight forward, but in modelling some expansion plans I want to try and actually wrap something around the planning process for backhaul capacity.

For example, 1 x 50M customer will clearly need 50M of backhaul from the POP they connect to, but what about 2, or 4, or 10 ?
You could easily surmise that 2 x 50M customers don’t need 100M of backhaul unless they are very heavy users, so let’s say they may need 75M, but this requirement for backhaul is realistically a sliding scale as the customers and bandwidth requirements grow the backhaul is not necessarily going to need to grow at the same rate.

I have worked this stuff out for some time now manually and had good results, our customers are happy, but I was hoping there would be some sort of calculation or formula that I could apply to some modelling figures which would give me a pretty close indication of requirements.

Thanks in advance

Regards
Paul

_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20170919/f54b4266/attachment.html>