[SWLUG] firewall bandwith shaping
steve at nexusuk.org
Thu May 3 09:46:19 UTC 2012
On 02/05/12 21:21, Matt Willsher wrote:
> Traffic shaping only really works from you to the Internet, rather than
> from the Internet to you - by the time the data hits your firewall it's
> already gone down your connection.
Not entirely true.
Ideally you want the traffic shaping on the ISP side since that directly
controls the traffic that's using the link. However, shaping on your
side will work, just not quite as well.
When a link between two routers on the internet starts getting
overloaded, the routers simply start dropping packets.
TCP basically starts transmitting slowly and gradually ramps up the
speed until packets start getting dropped. It then reduces the speed
and starts ramping it up again until packets get dropped. This
basically means that the sender won't continuously overload the path to
the recipient. This automatic throttling happens independently for each
Not all protocols have this automatic throttling function though - UDP,
for example, just blindly chucks packets over the internet. The
application itself needs to figure out how to deal with dropped packets,
overloaded links, etc. and it might not be as kind to overloaded links
as TCP is.
So if the ISP is doing traffic shaping, this just means that they start
throwing away packets for certain traffic to make the link appear to be
overloaded. Since it's the ISP doing the throwing away, this really
does shape the bandwidth in use - those packets never get transmitted to
you, so that bandwidth is free for other uses. Even badly behaved UDP
applications won't be chewing up your bandwidth because the ISP is
dropping the traffic before it gets sent to you.
But if the ISP won't do traffic shaping, you can do it yourself - your
router can throw away some of the packets it receives, and as far as the
applications are concerned, this looks the same as an overloaded link
(or your ISP shaping the traffic instead). The difference here is that
the packets you are throwing away have already travelled over your
connection, so that bandwidth isn't free for other stuff - you're
replying on the sender realising the link is congested and slowing down.
For TCP this works fine. For badly behaved UDP applications that have
no back-off mechanism, this won't help (and, in fact, may make things
worse since they probably have to retransmit the lost packets).
Look at the "tc" section of the Linux Advanced Routing and Firewalling
More information about the Swlug