1

Pardon me for my ignorance. I have not tried QoS nor traffic shaping/policing before.

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 FWs WAN interface is connected to an ISP router. The ISP router will just send traffic down the pipe to my FW as much as the bandwidth allows.

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

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

1

You queue or shape on traffic leaving a router, and it is really done on traffic outbound from your network. You can police (drop) traffic either inbound or outbound.

You shape and/or police outbound traffic to give different traffic flows differing amounts of the total outbound bandwidth.

Shaping the ingress traffic as it leaves your router into your network doesn't really accomplish much because you probably have greater bandwidth to your network than you do coming into your router from the WAN.

You can really only police traffic on the ingress of a router, and dropping TCP packets will cause the TCP receiver to miss segments and not ACK the missing segments, causing the segments to be resent, and the TCP sender will slow things down. This is inexact compared to egress traffic shaping, where you can actually give specific bandwidth numbers or percentages of the total bandwidth to different traffic flows.

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

Yes, it will cause TCP to take longer to send something to your network, but it will be sending at a reduced rate (lower bandwidth), giving other inbound traffic a chance. It will actually be consuming less bandwidth, but more data usage over a longer period of time. Do not confuse bandwidth and data usage. Bandwidth is the maximum number of bits a link can handle per second, but data usage is how much data is actually sent or received over a period of time. They are very different terms, and many people confuse them.

You can't really do much about connectionless (UDP or other) traffic clogging your inbound bandwidth, and a single host could practically monopolize the bandwidth inbound to your network.

| improve this answer | |
  • thanks for your reply "Shaping the ingress traffic as it leaves your router into your network doesn't really accomplish" - do you actually mean "Shaping the ingress traffic as it "enters" your router" ? – Noob Jul 10 '17 at 5:19
  • "when the receiver did not ACK the sender" , why will the TCP sender slow things down ? is it because TCP sender will actually wait before resending a packet and this somehow provide a workaround to slow traffic down for the sender ? – Noob Jul 10 '17 at 5:24
  • I mean the traffic coming into your network, as it leaves your router into your network. You shape traffic as it leaves a router, in either direction. TCP has built into it a method where a sender will slow sending as traffic is missing. This is a basic function of TCP, and there are questions and answers regarding that here if you search. – Ron Maupin Jul 10 '17 at 13:42
  • thanks for clarifying; not trying to play with words but how do you shape "ingress" traffic that is leaving the router ? -- wouldn't that be egress then ? are you refering to traffic that is leaving my ISP router and "ingressing" into my firewall ? – Noob Jul 10 '17 at 16:35
  • It is egress from the router, but it is ingress from the WAN. As the traffic that came in from the WAN leaves the router into you LAN, you could shape it, but that really doesn't do much since the LAN interface probably has a much higher bandwidth than the ingress WAN interface. – Ron Maupin Jul 10 '17 at 16:37
2

Why we'd want traffic shaping: imagine a SIP trunk and Internet access traffic coming in on the same WAN link - overloading the link with downloads would cause voice traffic to get dropped.

How it's done: you can shape ingress TCP traffic by holding back the TCP ACKs, so less traffic is sent than would be possible.

| improve this answer | |
  • "by holding back TCP ACKS" - do you mean to limit egress TCP ACKs to the far-end sender ? – Noob Jul 9 '17 at 17:07
  • When you delay egress ACKs the sender will throttle the ingress data stream, so effective bandwidth is reduced. Actually, you simulate a slower link. – Zac67 Jul 9 '17 at 17:47
  • how will the sender throttle the its sending ? is this a tcp feature ? when a sender doesn't receives an ACK, it will wait longer before resending ? (but how long? ) – Noob Jul 10 '17 at 5:21
  • TCP incorporates flow and congestion control. TCP segments need to be ACK'ed for new data to be sent (or old data to be resent when an ACK timeout is reached and the segment is presumably lost). TCP has algorithms that adjust send/receive window sizes and timeouts depending on the connection. When an ACK is delayed the send window continues to be filled and no additional data can be sent, reducing throughput. – Zac67 Jul 10 '17 at 14:07
  • so to prevent the ACK from getting back - we have to make sure that the receiver doesn't receive the payload - right ? that means we have to either shape/police the ingress facing the wan ? – Noob Jul 10 '17 at 16:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.