[Gllug] Bandwidth shaping

[Tom Gilbert]

* Rev Simon Rumble (simon at rumble.net) wrote:
> I'm trying to get my head around bandwidth shaping.  It's really doing
> my head in.
> 
> Okay so it seems you can only control outbound traffic and the aim of
> any shaping algorithm is to get the packet queuing to happen in a
> queue over which you have control.

You can control inbound traffic to an extent. Obviously, you can't
control how fast people send you data :) But you can put it in a queue
and even selectively reject some to make them back off, see the
documentation for the ingress filter.

> So would it be possible to use a loopback network connection to begin
> controlling inbound bandwidth?  Alternatively, if you have a machine
> running as a router between your computer and the Net connection,
> could you get it to shape the incoming traffic?
> 
> I don't think I'm the only one who has little interest in controlling
> outbound bandwidth and lots of interest in ensuring I can still ssh
> into my machine even though a big download is occurring.

Ensuring your ssh stays interactive is a factor of both inbound _and_
outbound shaping.

Queues on either side can prevent your tiny ssh packets getting through
quickly, so you need to up their priority in both directions.

To quote from the linux advanced routing and traffic control howto:
(http://www.linuxvoodoo.com/howto/HOWTO/Adv-Routing-HOWTO/Adv-Routing-HOWTO-9.html#ss9.2)
> A simple but *very* useful configuration is this:
>
> # tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1500
> 
> Ok, why is this useful? If you have a networking device with a large
> queue, like a DSL modem or a cablemodem, and you talk to it over a
> fast device, like over an ethernet interface, you will find that
> uploading absolutely destroys interactivity.
>
> This is because uploading will fill the queue in the modem, which is
> probably *huge* because this helps actually achieving good data
> throughput uploading. But this is not what you want, you want to
> have the queue not too big so interactivity remains and you can stil
> do other stuff while sending data.
>
> The line above slows down sending to a rate that does not lead to a
> queue in the modem - the queue will be in Linux, where we can
> control it to a limited size.
>
> Change 220kbit to your uplinks *actual* speed, minus a few percent.
> If you have a really fast modem, raise 'burst' a bit. 

There's a fairly decent example in that guide, that does what you want -
keeps ssh interactivity under load, by adjusting the queue priorities in
both directions.

I've played with his rules and they worked great, although I'm currently
playing with a ruleset that prioritises based on packet size, which
seems to work quite well...

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom at linuxbrit.co.uk    |
  ^^-^^   `-------------------------------------------------------'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20020403/fa65d88a/attachment.pgp>