Shaping/policing ingress traffic - make sense?

[SJ K]

Hi all,

Please pardon me for my ignorance. I have not try QOS nor traffic shaping/policing before.

But I have been pondering on whether can & why would we want to shape/police ingress traffic if you have no control over the next hop device.

Let's say my FW's wan interface is connected to an ISP router. The ISP router will just send traffic down the pipe to my FW using as much as the bandwidth allows.

Even my FW has some traffic shaping/policing rules in place, it will just cause ingress packets to get either queue or drop and the external sender to resend the drop packets (eventually consume more bandwidth for a longer period ?)

Am i missing the point ? Why would we want to police/shape ingress traffic ?

Hope gurus can shed light on this.

Thanks.

Regards,
Noob

[paul driver · Accepted solution]

Hello

Your are correct , you cannot control ingress traffic as by the time it hits your rtrs, The traffic has already traversed the wan link.

Although policing can be applied egress which as stated would drop or re-mark excess traffic, its usually an ingress feature and I would usually apply this on the Lan facing interfaces of the wan rtrs prior to the traffic hitting the input/output queues of the wan interface..

Shaping comes into play on your routers for traffic exiting your network,it used for QOS and It doesn't drop traffic it queues until it can be sent.

Also if your wan line rate exceeds your negotiated ISP CIR (committed interface  rate) it can be used for something called egress blocking - ( lets say the other side of the link has a lower CIR then you have, Shaping can prohibit overwhelming the other side of the link with traffic it cannot handle, so you shape egress at both ends.

res

Paul

[SJ K]

Hi Paul,

Thanks for your wonderful feedback.

In the event of the below setup,

[FW wan1] <===========> [ lan1 ISP R1 ] <===========> Internet

Can I say that -> with my FW's wan port connected to an ISP router, there is really no reason for me to shape or even police the ingress traffic coming from the ISP to my FW , am i right ?

Regards,

Noob

[Joseph W. Doherty]

Can I say that -> with my FW's wan port connected to an ISP router, there is really no reason for me to shape or even police the ingress traffic coming from the ISP to my FW , am i right ?

No.

[Joseph W. Doherty]

Your are correct , you cannot control ingress traffic as by the time it hits your rtrs, The traffic has already traversed the wan link.

That's not always correct.

If traffic is rate adaptive to drops, ingress policing may be used to "slow" ingress transmission rate.

[Georg Pauwen]

On a side note, in addition to Paul's post, since you said you have a firewall, if you have an ASA, be aware that the multicore models (5000-X) do not even support shaping. 

[Joseph W. Doherty]

Why would we want to police/shape ingress traffic ?

Usually as an attempt to manage your traffic for some purpose.

For example, say perhaps you have a policy that you doesn't allow more than 10% of your bandwidth be consumed by Torrent.  You might try policing Torrent traffic to 10% of you max bandwidth.

Now you're correct, even if Torrent keeps itself within the 10% bandwidth limitation, it's retransmissions will, overall, consume additional bandwidth, but what you're primary goal might be is to keep Torrent from using all your bandwidth at the expense of other "more important" application traffic also using the same link.

Also, with policing, believe it or not, you might actually be able, in some case, to actually reduce overall drops.  Or, decrease queuing latency.  Although your upstream ISP may "brag" they provide/support extremely large egress queues, to avoid egress queue drops, this can actually be detrimental to your traffic.

BTW, generally you cannot shape on ingress.

[SJ K]

Hi Joseph,

Thanks for your reply.. I am having difficulty visualizing it.

By the time the traffic was send to my router from an upstream, it would already have consume the bandwidth available , wouldn't it ?

Even if I have police setup on the ingress interface, dropping additional payload that comes in, the re-transmission will still take up the bandwidth available in pipe down to my router - no?

Regards,

Noob

[Joseph W. Doherty]

It depends on whether you're dealing with rate adaptive traffic or not.

Rate adaptive traffic usually slows its transmission rate when drops are detected.  Policing at a rate less then your link capacity attempts to signal to a flow to slow down, hopefully keeping its transmission rate below the policed rate.

Basically policing on ingress will impact the traffic much like the other side's egress interface will.  I.e. if senders send too fast, the upstream egress interface will also drop traffic, creating the same possibility for retransmission you're concerned about.

Think on this.  Assume you have a 100 Mbps link.  All the ingress traffic will be forwarded to a 10 Mbps egress link (same device).

Consider the overall impact to your ingress traffic whether you have a 10 Mbps policer on the ingress port, or not.  Is there a difference?

[SJ K]

Hi Joseph,

Thanks for your reply.. i might be wrong...

Think on this.  Assume you have a 100 Mbps link.  All the ingress traffic will be forwarded to a 10 Mbps egress link (same device).

My 10Mbps egress link probably would not be able to queue so much traffic ? Thus having the 10Mbps policer on the ingress reduce the processing effort require by the router ?

But how does the above link to policing ingress on the WAN side if my LAN side has a larger bandwidth then my WAN ?  --> this will really depends if i am dealing adaptive rate traffic right ?  I am dealing with udp video streaming that is not adaptive, doing an ingress policing will not help nonetheless, am i right ?

Regards,
Noob

[Joseph W. Doherty]

My 10Mbps egress link probably would not be able to queue so much traffic ? Thus having the 10Mbps policer on the ingress reduce the processing effort require by the router ?

Yes and yes. But for the second question, you might want to police on ingress for other reasons.  For example, say your ingress might be forwarded to several egress interfaces, but you want to manage the aggregate bandwidth.

But how does the above link to policing ingress on the WAN side if my LAN side has a larger bandwidth then my WAN ?

It wouldn't if your only concern was LAN bandwidth consumption.

this will really depends if i am dealing adaptive rate traffic right ?  I am dealing with udp video streaming that is not adaptive, doing an ingress policing will not help nonetheless, am i right ?

Again, it depends on what you're trying to accomplish.  Some video streaming traffic is rate adaptive, but if you're dealing with traffic that's truly non-adaptive, yes, an ingress policer won't help you with that traffic, beyond what it might accomplish for other downstream interfaces, but it's unlikely all your traffic is such.  Also for such traffic, if you drop any of its packets, for any reason, the source generally will not retransmit the dropped packets and the remaining packets not dropped might be useless.

Also again, for such a case, what happens if the upstream device egress port doesn't offer sufficient bandwidth?  How does it differ from what the policer will do?

BTW, I've been in the situation where an ISP wouldn't provide QoS on their egress interface but I was able to, somewhat, manage ingress traffic using an ingress policy with class policers.  I can tell you it works, although not nearly as well as an egress policy where you have queues you can prioritize.

[SJ K]

Hi Joseph,

Thank you so much for your replies.

So in the overall essence (pls correct me if i am wrong),

police ingress traffic -> does not reduce the overall bandwidth/data usage from the sender, but will probably reduce current bandwidth usage down the pipe due to certain traffic's rate adaptive nature

shaping ingress traffic -> not useful as ingress traffic has already hit your router and bandwidth down the pipe taken up; not required as well as lan side of the router normally has a larger bandwidth then on the way.

police/shaping egress traffic -> provide a direct way to buffer sufficient bandwidth for other more important traffic to pass through.

right ?

[Joseph W. Doherty · Accepted solution]

police ingress traffic -> does not reduce the overall bandwidth/data usage from the sender, but will probably reduce current bandwidth usage down the pipe due to certain traffic's rate adaptive nature

Right, but as you noted in some of your other posts, some traffic will be re-transmitted so overall total bandwidth usage might be increased.

shaping ingress traffic -> not useful as ingress traffic has already hit your router and bandwidth down the pipe taken up; not required as well as lan side of the router normally has a larger bandwidth then on the way.

Shaping generally not supported on ingress.  However, it could be used on egress to drop packets which will likely impact rate adaptive traffic.  Also, however, a shaper queues while a policer does not, so impact to traffic may differ.

I.e. yes, not required, but neither is a policer.  Also, not really an issue of a LAN interface having more bandwidth, it's more to due with what QoS tool best accomplishes your goals.

police/shaping egress traffic -> provide a direct way to buffer sufficient bandwidth for other more important traffic to pass through.

Again, a policer doesn't buffer.  Both may be used to try to provide sufficient bandwidth for more important traffic, although since shaper's buffer, you may have the option to prioritize how traffic is dequeued.

[SJ K]

Hi Joseph,

Thanks a million for the insight.

On the side note, if you don't mind.. the queue that the shaper is using is not the output queue  that we are seeing in sh int right ?

How do we see the  shaper queue generally (i have no specific cisco model in mind) ?

Regards,

Noob

[Joseph W. Doherty]

Whether you can see the shaper queue (or queues) depends on the platform and how you've configured the shaper (or shapers).

The old interface GTS shapers did often to appear to have their overall queue depth reflected in the interface queue stats.  (They often supported a command that would show you how many active flow queues, and number of packets in each.)

The later CBWFQ class shapers often have some stats attached to the class stats but usually don't provide any flow queue stat information.

(I recall GTS shapers seemed to always use WFQ, but the later CBWFQ shapers might have only a FIFO queue or use subordinate child class queues.)