Hi im working on a UNI project. Im just wondering how you calculate or simply know how fast a link a company needs. Ive been looking at BT's IP clear MPLS option as base for my project. It offers speeds from 56K to Gigabit, I understand it depends on what you need it for but how do you work it out?
Don't think of it as "speed" but capacity per unit of time.
Try and establish the sources and destinations of normal traffic flows.
What is the proposed topology ?
Are there specific app requirements for latency ?
That will give you very rough sense of how things might go. Be prepared to change your assumptions based on evidence.
Thats how long a string is....
Its an MPLS setup with 5 sites around the UK. Nothing specific, it will be used to move files between sites, mainly to and from the headquarters. The files can be up to 1gig in size and up to 60+ employees at a remote site could be trying to download them at the same time. The internet traffic from each site will also go through the central site to the internet connetion.
Aghh how does one know
Is there anything you can do a traffic study on right now? Its not perfect but it will give you some sort of trend to work with.
I would consider some sort of ethernet based solution, with variable capacity available so you can get more bandwidth
if you need it.
I'd be tempted to start at about 25 Meg for my first site. Do try and get metering in place early.
Aggregation will be your bigger issue at the headquarters. Again what do the UK carriers offer as far as high speed mpls services.
In my last life we ran 2 gig/e links from the POP. worked out quite well.
A few more thoughts and perhaps others can help build on this list:
* Like vmller said can you give us a better sense as to how much latency you'll tolerate on those file transfers? Given a perfect line (more about that in a minute) moving a 1GB file across a 1Gb line will take you 2 hours; across a 56K line, errr,don't think about that.
* Probably obvious but there's no such thing as a perfect line. Throughput is a combaintion of loss, latency, and line speed. BT's stats here: http://ippm.bt.net/ suggest your latency will be, what, 10ms if you're lucky? If Loss is just .5 ms then even on a 1G connection your going to see only 16.5mbps of throughput per flow/application or about 138 hours to move that 1G file.
* Carriers always cite loss rates really low, like 0%, but that's misleading. Those numbers are just their backbone, typically, and not the local loops. They numbers are also averaged over time and not instantious. MPLS networks typically have anywheres from .1% to .5% loss (or more).
My big advice to you is consider SOMEONE'S WAN optimizer. (Self servig here, I know, given that I work in Silver Peak, but it really makes tons of sense for you here). A WAN optimizer will remove the redudnant data, compress the rest and boost line peformacne by like 5x -10x here.
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
For bulk transfers, you calculate how much data needs to be transferred in how much time. For example, if we had a database backup of 10 GB, and a time window of 5 hours (e.g. midnight to 5 AM), you need to transfer 2 GB and hour or about 4.5 Kbps. (An actual production calculation would need to allow for how the protocol works, so for example if using TCP, you might need to allow an extra 30% to allow for TCP overrunning available bandwidth, slowing down, and speeding up. A constant bit rate streaming protocol might not need similar allowance.)
For interactive traffic, you need to know your expected average transfer rate and then add a cushion to minimize multiple flow bandwidth competition queuing delays. Allowance varies on number of flows and per flow bandwidth usage relative to overall bandwidth. Generally fewer flows and higher percentage of overall bandwidth need larger cushions. For example, few 100 Mbps hosts running across 1 Mbps might need 3x their average aggregate bandwidth usage. Many 100 Mbps hosts running across a gig might be fine with only an extra 20% above their average aggregate.
Mixing bulk and interactive often will require 3x or more average aggregate bandwidth usage unless you can use QoS policies to treat each separately on the shared link. If you can use QoS, class bandwidth allowance can generally be as the above.
Other than utilization, more bandwidth, if you can afford it, also allows transactional traffic to arrive faster. I.e. the above bandwidth recommendations for transactional traffic was to minimize queuing delays, but bandwidth can also be used to minimize serialization delay.
From what you describe, your key factor would be sharing Internet traffic with file downloads. I.e. whether you can use QoS, or not, may have a huge impact on your bandwidth requirements.
One often overlooked issue is even if you have LAN like bandwidths for WAN connections, you can't "buy" LAN like latencies.
I'll add this to the time my hands, typing at a PC keyboard, were on one of Philadelphia's major TV networks 6 PM news.
Thanks Leo for letting me know!
Dave Greenfield wrote:
No, he paid me for the PR!
Yes I did - and I want a refund, or at least partial refund, if you're not going to spell my name right - it's "JosephDoherty" not "JospherDoherty" -
Even so, I've been kidding others at work I'm now a recognized authority or expert as I've been (extensively) quoted in NETWORKWORLD. Not to mention how I ran out and bought 100 copies to share with all my friends and acquaintances.
Laugh - just proves your point on your other post about error rates in transmission and there not being such a thing as a perfect line.
Yes I did - and I want a refund, or at least partial refund, if you're not going to spell my name right - it's "JosephDoherty" not "JospherDoherty"
You can't get the refund Joseph because the "refund" went to JospherDoherty instead.
Not to mention how I ran out and bought 100 copies to share with all my friends and acquaintances.
Did you autograph the copies/pages and have them etched in bronze?
leolaohoo wrote:Yes I did - and I want a refund, or at least partial refund, if you're not going to spell my name right - it's "JosephDoherty" not "JospherDoherty"
You can't get the refund Joseph because the "refund" went to JospherDoherty instead.Not to mention how I ran out and bought 100 copies to share with all my friends and acquaintances.
Did you autograph the copies/pages and have them etched in bronze?
Couldn't properly autograph them because of the name issue, but I hadn't even considered having them etched in bronze (slap against forehead)!
To Liam (original poster), hope this little interplay between Leo and myself (and Dave too) wasn't a problem. If you need additional information, or the serious replies didn't fully answer your question, please let us know.
Perhaps the biggest issues you might contend with sizing a WAN link, is what's actually available and most important of all, how much is it going to cost?
One interesting problem when working with WAN links vs. LAN links, surprisingly high (100 Mbps or faster) LAN like bandwidths can be much more difficult to take full advantage of then similar bandwidths on a LAN link. Dave's "serious" posting touches on some of those issues.