Generally speaking … to answer the question you’d likely need to at least consider the business oriented, technology parameters, and application specific components requiring emphasis for the specific location(s) involved.
A good answer to the question requires a detailed understanding of the kinds of traffic the proposed network is intended to handle. For example, streaming video often requires high net bandwidth, but can use packet aggregation and may be able to accept the latency inherent in e.g. an asymmetrical satellite downlink.
In contrast, heavy multi-user VOIP might require symmetrical up and downlinks, in which per-user latency and the ability to handle many packets-per-second are much more important to performance than net bandwidth.
Or, you may have hybrid requirements in which part or all of the network has to handle multiple data types and amounts with varying latency requirements.
Once you understand the various network use scenarios, planning becomes largely a matter of understanding peak vs average use per node, as well as local vs pass-through data flows per node, ….. and designing node capacity, queuing, bandwidth shaping and limiting, and overall system requirements accordingly.
Yes …. every company is different hence every network is unique.
Sometimes, network requirements are driven by vps services
the applications, sometimes it is the other way around – applications are engineered to cope with certain network realities.
Here is a good example:
If a company has operations all across the world, round-trip delay will be at the top of my concerns. Since realistically the delay between US and China or India will be in the range of 300ms round-trip (or more), the applications will have to be designed with this in mind. For example interactivity across-the-pond is not going to work very well no matter how much bandwidth you throw at it.
To over simplify ….. some common factors will be number of users, criticality of time sensitive information, geographical spread/locations, types of applications, data only or data and voice. You also have to think about whether you are incorporating hubs or data centres. Last but certainly not least at present is what budget do you have to work with because knowing that might simplify some of your decision making.
The two countervening issues are cost and organizational applications demand/expectations.
Depending on an organizations priorities, start with one of the two issues above (i.e. if they’re driven by cost start there since any application driven model will be unappreciated or ignored).
If starting with cost – you’ll likely be building a network model that forces application needs through priority based networking filters to ensure applications are treated with the correct priority based on organizational need and priority.
If starting with applications, be sure to include anything needed during the future 12 months (i.e. don’t use historical demand for anything but a starting point). Needs beyond the 12 month period should be considered to ensure the equipment and services chosen will allow future growth.
To start the process, meeting and discussing needs and expectation with all key stakeholders is critical. This includes IT, Finance, Sales, Marketing and Operations. Anyone left out of this early discovery will likely create gaps in the analysis that will come back to bite you later.
Bandwidth should also be segmented on need across the WAN, internal backbone, distribution network and access network. Also method of delivery is important (i.e. DSL, T1, DS3, OCx, Optical, copper, Wi-Fi). Breaking things out this way will also ensure you have the right technology, enough redundancy, and user flexibility to have a tight fit with the end user and organizational needs and expectations.
Equipment decisions flow from the earlier points and should be defined towards the end of the process. Adjustments to the plan can be made at this stage dependent on equipment capability – assumptions about equipment capability early on are a sure way to have your plan driven by the equipment vendors (not a good thing). For instance, a vendor I know of has some very powerful systems for using wireless at the primary access network ….. but many customer’s made assumptions early on that this was not possible – the results being they over spend on wired technology.
Once a draft plan is created, this should be presented back to the same set of stakeholders you met early on to ensure you’ve captured everything and have one last chance to integrate any changes required since the 1st discussion. Also, this gives you a chance to explain options to the plan and gain buy in to the preferred options.
A common practice is to “find the bottleneck”. In designing a bandwidth solution, you can only be as fast as the slowest component.
In practice it is best to map out two things:
1. Current data rate and maximum capacity
2. Desired data rate
From there you can look at the whole chain and make decisions around what you will do.
Do I need to change network service providers? How much throughput do I need to design in? There is no sense building a ferrari if you only have local driving at low speeds.
But to the other extreme, there is no use designing a small 4 cylinder engine to drive local streets if changing over to the expressway could get you there faster.