Re: shaping: dividing bandwidth between router & NAT hosts

Policing != shaping

> Huh? Why not just this?
> tc qdisc add dev eth0 handle ffff: ingress
> tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip src \
> 0.0.0.0/0 police rate ${DOWN}kbits burst 10k drop flowid :1

--
Cory Oldford
PeaceWorks Computer Consulting
#2 - 396 Assiniboine Ave, Winnipeg
204 480 0314 --or-- 519 725 7875, ext 610.

----- Original Message -----
From: "green" <greenfreedom10@gmail.com>
To: debian-firewall@lists.debian.org
Sent: Friday, 12 February, 2010 15:41:38 GMT -06:00 US/Canada Central
Subject: Re: shaping: dividing bandwidth between router & NAT hosts

Stephan Balmer wrote at 2010-02-12 11:55 -0600:
> > An automatic detection of down/up bandwidth would be great, but it is not
> > necessary. Hmm, is there a way to set up something to test
> > pseudo-automatically, like try wget download while the box is booting...
>
> Doing it just once would be fairly unreliable. If for some reason the
> initial download was slow, the system will limit itself way below a feasible
> rate. Not that I have a quick solution. When I tinkered with this stuff I
> figured that there are basically two parameters you can watch:
> 1. ping round-trip time to the router on the other side of the bottleneck
> 2. fill state and flow rates of the queues
>
> The ping round-trip tells you how long it takes to get through the
> bottleneck up and down. You could monitor that and when it starts going over
> half a second your script would gradually squeeze the bandwidth choke. That
> way the system would try to keep latency low in the face of congestion.
>
> One problem with this is that you get only compound time up+down, and you
> don't know for sure which one is congested. This is where the second part
> comes in. By monitoring flow rates the gateway could learn correlation
> between flow rates and round-trip times and thus determine the maximal link
> capacity, and even adapt to changing capacity.
>
> I've got it all figured out, I'm just too lazy to implement it. :-)

I wish all that was implemented in Linux shaping somehow...

> > So, I just need to do ingress policing on WAN interface at 10% less than tested
> > down bitrate...
>
> Yes. You'll need IMQ for this.

Huh? Why not just this?

tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip src \
0.0.0.0/0 police rate ${DOWN}kbits burst 10k drop flowid :1

> > ...And egress shaping on WAN interface. I see another message with some more
> > tips for that, and of course examples online also.
>
> Do this first, it's a lot simpler. Chances are you'll decide you don't need
> ingress shaping after all.

And use those "great big FIFO ISP queues" I have heard about?

But yeah, if ingress shaping does not help significantly (for interactivity),
then I certainly am better off without it. And then I would not need to test
down bandwidth.