Re: shaping: dividing bandwidth between router & NAT hosts

I have some good histories about routing and linux, I have a little blog to share them, I have what I believe you need regarding internet access and routing and nats and so on.

Stop by and if more help is need it, let us know.

http://soad1982.blogspot.com/2010/02/advance-routing-on-linux.html



--
Jose Valdivia
Firewall Enginner

Perot Systems
CCSA CCSE WCSA NCMA NCMP

On Thu, Feb 11, 2010 at 9:15 AM, green <greenfreedom10@gmail.com> wrote:

Stephan Balmer wrote at 2010-02-11 03:04 -0600:

> > I am working on setting up a router/server running Debian Squeeze.  I have had
> > a lot to learn and have managed to understand iptables and have mostly set up
> > filtering.
>

> What sort of link are we talking about? Symmetric/Asymmetric? Bandwidth?

Well, sorry but it could be anything.  I may at times have to move the router
and my only requirements of the connection is that it be reliable, at least say
20kilobytes/s, and have a public IP address.

> > Now I would like to set up traffic control.  I have been reading documentation
> > and have been looking for an eth0 ingress way to delay packets in order to
> > control download bandwidth, but maybe ingress shaping is not a viable solution.
> > Perhaps it is the ACKs that I need to shape instead: delay the outgoing ACKs to
> > control downloads and delay the outgoing data to control the uploads.  Will
> > that work?
>

> I haven't looked lately, but on Linux you'll propably have to set up imq devices
> for ingress shaping. Ingress shaping is indeed controversial. It is also a lot
> simpler than delaying ACK packets based on traffic going the other direction.

I would rather not use something controversial, or preferably anything else not
included in standard Debian squeeze.

> Personally I wouldn't delay ACK packets, but prioritise them over other
> packets. They don't hurt your throughput.

I understand that ACKs won't hurt throughput, but have supposed that delaying
them would help control downloads.  If the sender does not receive an ACK until
later hopefully they will see a low-bandwidth link and slow down.

If I prioritize ACKs over other packets, won't that make it even harder to
control downloads?  That is, ACKs go out first so the sender sends faster?


Take this scenario, with these interfaces:
eth0: WAN
eth1: host connected
wlan0: random

Say the router starts downloading a Debian ISO and uses all the bandwidth at 80
kilobytes/s.  Now the eth1 host wants to download another one.  I would like
ideally to be able to say eth1 gets 80% and local gets 20%, but that seems to
be difficult to accomplish.  It seems that it would be a while (if ever) before
eth1 gets a significant amount of bandwidth.  Add to this wlan0 which will be
unsecured and may be using lots of bandwidth (perhaps I could just give it a
flat limit).  Is there some way to balance this, if loosely?  Perhaps just
using a certain TCP congestion algorithm?  Or can I prioritize ACKs from the
different interfaces?


Thanks.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkt0HwQACgkQ682C+dBP+oR5owCfTWEoQXeUELvnX93RunTXQuoi
WLcAninViUZj4+7xv+Xcg9FBPg3ridO9
=muoD
-----END PGP SIGNATURE-----