QoS for inbound Internet traffic

[atsukane]

Hi All,

I'm new to QoS so appreciate any help/guidance :)

There's a requirement to limit bandwidth usage for a specific application's inbound traffic. 

This app pushes data up to S3 bucket in AWS, data gets processed by the vendor, and once the data is processed automatically downloaded from S3.
During the test over a 500Mbps link, initial upload was using average of 20Mbps, but subsequent download spiked to over 240Mbps briefly. The vendor has confirmed no way of throttling b/w usage from their app.

As I do not want this traffic to impact other business apps like O365 in production environment, I want to limit the bandwidth usage for the inbound traffic somehow. 

host/vlan <=> CAT6707 15.2(1)SY7 <=>  inside ASA5555 9.4(4)29 outside <=> Internet <=> S3

In this scenario, would it be possible to use QoS to limit bandwidth for INBOUND traffic? My initial thought is that by the time the traffic hits ASA it's already used up a chunk of b/w, so it's too late to do anything, unless we can do something during initial upload phase to somehow mark the traffic and that is applied to the download process? 

Many thanks,

[omz]

Hi 

As far as I know .. ASA cannot do QoS marking but it does preserve and forward.

S3 does allow bandwidth config - 

https://docs.aws.amazon.com/cli/latest/topic/s3-config.html#max-bandwidth

the application should allow setting bandwidth. If it doesn't ... then its not well design I guess. 

[atsukane]

Thanks omz.

Yes, unfortunately the app vendor has confirmed that there's no way throttling bandwidth from the app.

I was looking for alternatives and limiting on S3 was one of them, so thanks very much for the link.

Regarding S3, to your knowledge is this something that you have to do every time or set it once and the config sticks from then on?

As for the QoS on ASA, thanks for the clarification, so I think that the answer is it's impossible to achieve this on ASA alone.

We also use Zscaler for Internet access. We do not currently subscribe to their Bandwidth Control service, but this could be another alternative as this would have benefit of prioritising business critical apps like O365 as well albeit additional cost.

Many thanks,

[omz]

Glad if I can be any help .. 

As far as I know, the max_bandwidth setting is used with S3 calls via CLI or API. 

The application is most likely calling the S3 API to upload/download content. The max_bandwidth parameter, either the app is not using these parameters when calling the API or the parameters are coded in the app.

Proxy is another option to either limit S3 traffic or priorities critical traffic.

Is the app using multiple concurrent requests? One option could be to limit concurrent requests.

app vendor not taking any feature requests for future development? :)

[atsukane]

Thank you.
I'll speak to the vendor and confirm those points.

[omz]

You welcome. Thanks for hitting helpful button :)

please keep this thread open .. there are a lot of clever people here .. someone might come up with a better solution.

[Joseph W. Doherty]

With inbound traffic, many Cisco network devices (ASA?) support some form of rate-limiting/policing.

Policing traffic "downstream" can be somewhat effective in managing the sender's transmission rate, this assuming the sender "notices" lost packets and slows its transmission rate when that is noticed. (For example, traffic using TCP will slow itself.)

Some senders will also slow their transmission rate if they "notice" a jump in RTT (presuming there's congestion). For the latter, shaping the ingress traffic might slow the sender, w/o quite the adverse impact of dropping the sender's traffic.

The prior, though, will see quite a variation in received transmission rate, including often burst above the desired maximum (upstream of your QoS management point).

The best approach (assuming QoS cannot be done on the sending end), though, requires use of a special traffic management appliance. These devices can "spoof" the sender in such ways to manage its transmission rate. For example, with TCP, the device may delay TCP ACKs (NB: you can also do this on some Cisco devices, but not with the precision of a dedicated appliance) and/or spoof the receiver's RWIN. The downside to these devices are several, not forgetting their additional expense to acquire and manage, they aren't 100% sure in all situations, and they need way to manage the traffic of interest.

[atsukane]

Thank you Joseph.

If I was to use traffic policing policy to limit inbound traffic exceeding say 200mb would look something like this? 

ASA(config)#access-list s3_eu-west1_acl extended permit ip s3_regional_networks host x.x.x.x

ASA(config)#class-map s3_eu-west1_class
ASA(config-cmap)#match access-list s3_eu-west1_acl

ASA(config)#policy-map s3_rate_limit_policy
ASA(config-pmap)#class s3_eu-west1_class
ASA(config-pmap-c)#police input 200000000 conform-action transmit exceed-action drop  

ASA(config)#service-policy s3_rate_limit_policy interface outside

As for the traffic shaping option, do I just replace the 'police' statement to 'shape average' ?

Also I'm not quite sure 'Burst bytes' would do in policing policy.

Many thanks,

[Joseph W. Doherty · Accepted solution]

Sorry, I'm unfamiliar with ASA QoS features. On a Cisco ISR, you would just have police (or shape) #. Then for a policy with a policer, if could be applied as an interface ingress or egress police (shapers can only be assigned as egress).

As to burst bytes, basically physical transmission is a line rate, so the burst determines the amount of data that can transmitted during some measured period. If the transmitted data exceeds the allowed capacity during the measured time period, excess is dropped with a policer (or queued with a shaper). At the end of the period (known as the Tc), the capacity is reset.

Some further explanations on CIR, Bc and Tc (and Be):
https://community.cisco.com/t5/routing/bc-and-be-in-policing-question/td-p/2604525
https://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/19645-policevsshape.html
https://brbccie.blogspot.com/2012/12/a-different-perspective-on-cir-pir-tc_1785.html

[atsukane]

Thanks very much Joseph,  appreciate it.