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 wha2tsoever (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
On an ISR, egress FQ would probably mostly eliminate the issue you're seeing for uploads. Unfortunately, the download issue is not so easy to deal with using ISR QoS.
The download issue migth be easy to mitigate with QoS on the ISP's egress, but almost all ISPs won't provide it (although they will often be happy to sell you more bandwidth).
There are some ISR QoS techniques that can somewhat regulate ingress bandwidth, but they don't generally work exactly as we desire.
There are also 3rd party traffic management applicances that can do much more than an ISR to regulate ingress bandwidth.
What you migth try:
policy-map shapedOut
class class-default
shape average 17000000 !I'm shaping 15% slower to allow for L2 overhead
policy-map shapedIn
class class-default
shape average 10000000 !I'm shaping much slower to congest and drop so to slow sender before downstream bandwidth is saturated - you can experiment with this bandwidth - lower bandwidths will likely better control ingress saturation but at the cost of not using all your downstream bandwidth when you want
service-policy FQ
policy-map FQ
class class-default
fair-queue
interface (toward ISP)
service-policy output shapedOut
interface (toward LAN)
service-policy output shapedIn
