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
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.
PS:
One often overlooked issue is even if you have LAN like bandwidths for WAN connections, you can't "buy" LAN like latencies.
