Disclaimer
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.
Liability Disclaimer
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.
Posting
If you monitored a 4 Mbps WAN link over a number of months, and saw that the bandwidth utilisation never peaked above 1.8 Mbps, would it be safe to assume that you could reduce the bandwidth on the link to 2 Mbps without having an impact on performance?
No, I don't believe that's a safe assumption.
Obviously burst traffic that pushes the utilisation over 2 Mbps will be affected, but I wondered if there were any of factors that come into play that would affect performance.
Yes, many.
Additional comments . . .
Basically, all application traffic would like, from the network, zero delay, no frame/packet loss and infinite bandwidth. Of course, providing such is impossible.
You can work to provide the least delay, least frame/packet lost and most possible bandwidth, which if provided, generally makes application traffic "happy", but this can be prohibitively expensive. So, what we really work toward is providing, at least, the minimum delay, minimum frame/packet lost and least amount of bandwidth that a network application will consider acceptable or good for its service requirements. Service requirements tend to vary much based on the nature of the network application being supported.
For example, given the stats you've provided me, if all your traffic was e-mail server-to-server data, not only might reducing the bandwidth from 4 Mbps to 2 Mbps be fine, if you further told me e-mail only was required to be successfully transferred within 24 hours, perhaps even much less than 2 Mbps might be fine too. The real question would be, how much e-mail volume is transferred across 24 hours and do you have enough bandwidth to support that volume in 24 hours?
Conversely, if you told me all your traffic was (just) VoIP using g.729, dropping to 2 Mbps might be very damaging to the the quality of your VoIP calls. Further, assuming your stats are from typical 5 minute polls, the 4 Mbps you have now might actually be insufficient.
If you have mixed traffic types crossing this link, each needs analysis against the aggregate usage.
Doing capacity planning (or monitoring) "right" can be rather involved; i.e. many factors. Because of this, most seem to take the practical solution if users complain, add bandwidth until users stop complaining. (No reason why the inverse wouldn't work too, i.e. reduce bandwidth until users complain. Intentionally breaking the network can be damaging to one's reputation, though.)
BTW an empirical approach doesn't work too badly although many don't realize how even basic QoS can skew the bandwidth "needed". For example, if your 4 Mbps is using FIFO queuing, user perceived performance might be just as well with 2 Mbps if you use fair-queuing. (Note: without knowing much, much more about your traffic, not saying this would be actually true for you.)
PS:
Also BTW, some Cisco IOS images have a very interesting bandwidth analysis feature, look for Corvil Bandwidth on Cisco's main site.
