[SWLUG] firewall bandwith shaping

[Steve Hill]

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 
TCP connection.

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 
project docs.

-- 

  - Steve