Very Computer

I have a home LAN of 5 machines that for internet connection use a linux
box that masqurades the traffic over a 56k modem.  (Yes - this is slow,
but free for me). I want to restrict the ammount of bandwidth users have
over the ppp0 interface, as someone doing an ftp download can slow the
link for other users uses (e.g. telnet, web) that have high interaction
for them.

Ideally I would like to let each user have 100% bandwidth if it's just
them, then say restrict to 75% capacity when more than one machine is
using the ppp link.  This way the ftp transfer continues at a reduced
rate and the telnet session still has more than enough capacity to be
useable.  If however the ftp and telnet originate from the same IP
address then no change will be made and the user himself will have to
slow his usage. Also the Linux box runs its own services such as DNS and
sendmail/fetchmail.  Some of these can take a low priority like
sendmail, others like DNS cant.

Any ideas on how best to implement this would be most appreciated.  I
have been looking at quality of service and traffic shaping but know
very little of these,.  The LAN is set up as follows.

Two subnets (192.168.100.x and 192.168.10.x), both ethernet (one 100Mbs
the other 10Mbs)
Linked to a seperate NIC on the linux box (SuSE 6.0 - kernel 2.2.9)
Each PC on the LAN uses this as the default gateway for traffic
The Linux box will forward between these two ethernet interfaces, and
masqurade anything going over the modem, using IPCHAINS.

Thanks,
Chris

Quote:

>The other option is iproute2, which is probably going to become
>the standard in the future.  I don't know so much about this,  but
>I believe it allows such things as traffic shaping by port, etc.
>When I last looked, there wasn't much documentation for this
>(although there isn't much documentation for shaper, either, but
>at least shaper is available as a RedHat RPM.)

I wonder if iproute2 is related to this new Quality Of Service code
and packet scheduling system. That may be worth looking into, giving
things like telnet low latency and ftp high latency. An idea I had but
have never tried would be to drop the maximum transfer unit (MTU) for
the link. This increases overhead due to fragmentation and more packet
headers but a 1500 byte packet takes some time to transfer over a modem
so contributing to the problem you describe.

 - Richard.

--

  _/  _/    _/    _/      Web Page, CV:   http://www.littondale.freeserve.co.uk
 _/_/      _/    _/       Dance (Ballroom, RnR), Hiking, SJA, Linux, ... [ENfP]
_/  _/  _/_/    _/_/_/    PGP2.6 Key ID: 0x0FB084B1     PGP5 Key ID: 0xFA139DA7

Are you sure you need this?  TCP is already designed to attempt to share
bandwidth fairly, in my (admittedly limited) understanding.

However, you might get somewhere with tweaking packet size limits (MTU and
MRU) - the rules here are:

1. small values encourage better interactive response
2. Large values increase throughput in bulk transfers like ftp
3. Fiddling with either often makes everything worse :-(

--
Anahata

020 7229 6076 (H)     0976 263827 (M)    020 7598 0208 (F)
======= brought to you from a Debian 2.1 GNU/Linux system =======

Maybe this could help you:
http://icawww1.epfl.ch/linux-diffserv/

Torsten

In my opinion, traffic shaping is not same as diffserv
traffic shaping is for application
diffserv is for IP packet

Quote:> Maybe this could help you:
> http://icawww1.epfl.ch/linux-diffserv/

> Torsten

I have set the ethernet and ppp devices to have the same MTU of 1500 - it
seems stupid to have them differing, and the modem MTU is set by the ppp
server at the other end of the link.  The reasoning behind the restriction is
that FTP can take a back seat (it can take all night for all I care) but
telnet should take priority (as its painful watching pine take forever to
redraw the screen)

Chris

    So if I wanted to restrict a host (on a given IP) to say 3k/sec over the
ppp connection *in both directions* then am I right in assuming that this is
possible using traffic shaping (re shaper).  And this would leave, say, a
guaranteed 2k/sec for all other users, possibly up to the max of 5k/sec
depending on the useage of the 'shaped' host?

    Or am I still barking up the wrong tree?

Chris

N.B. Telewest here in Bristol are still reporting *major* problems with
their cable modem service - this was going to be my way out of this *
analogue mess - looks like time to shotgun a few modems together and learn
about load balancing!!

<snipped stuff about shaping>

Quote:

> N.B. Telewest here in Bristol are still reporting *major* problems with
> their cable modem service - this was going to be my way out of this *
> analogue mess - looks like time to shotgun a few modems together and learn
> about load balancing!!

Every time I ask about cable modems they appear to be about 6 months
away. Next spring was the latest estimate, although there was a time
they were saying they'd be out for November 1998!

Ah well, at least some of us can take advantage of the free calls while
we're waiting.

Jon.

Telnet? You want ssh -C (if using ssh1.x), surely? :)

Seriously, I've experienced a pretty good speedup using that for redirecting
Debian updates of a night. It also makes my connection from screaming.net to
the custard account more bearable - it's the equivalent of gzip -6 by default,
IIRC, with a similar scale from 1-9 (although you don't want to spend too much
processor time compressing stuff when it could be sending it over the line).

What I do is set up local port forwarding so that apt thinks its source is
localhost:1234 or something random, which routes out to www.mirror.ac.uk:80
via custard. My average download speed of .deb archives has gone from
screaming.net's regular 2.5K/s up to about 4K/s. Your telnets should do better
- well can you type that fast anyway? ;)

~Tim
--
| Geek Code: GCS dpu s-:+ a-- C++++ UBLUAVHSC++++ P+++ L++ E--- W+++(--) N++
| w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y-
| The sun is melting over the hills,         | http://www.glutinous.custard.org

As I understand it (and I may be wrong), you can only effectively
control the traffic rate at the *sending* end.  

Martin
--

Registered Linux user #9257 - see http://counter.li.org                   -o)
"Only wimps use tape backup: _real_ men just upload their important stuff /\\
  on ftp, and let the rest of the world mirror it ;)"  - Linus Torvalds  _\_V

I dont know what you mean by "effectively"; but by manipulating the tcp
window-size
you can control (to some point...) the sending side, too.

Quote:> > As I understand it (and I may be wrong), you can only effectively
> > control the traffic rate at the *sending* end.
> I dont know what you mean by "effectively"; but by manipulating the tcp
> window-size
> you can control (to some point...) the sending side, too.

Indeed; I'm not a TCP/IP expert.  The point I was trying to make is
that if you control the sending end, you can *enforce* limits; if you're
at the receiving end, while there are things you can do to affect the
sending rate, you can't *control* it as effectively.

"Effectively" was probably a poor word to use in an international
forum, since I used it with a fine meaning that wouldn't necessarily
have been understood by even native English speakers.

[Followups set]

Martin
--

Registered Linux user #9257 - see http://counter.li.org                   -o)
"Only wimps use tape backup: _real_ men just upload their important stuff /\\
  on ftp, and let the rest of the world mirror it ;)"  - Linus Torvalds  _\_V