LARTC - Dec 2001 - sfq as solution to "Small ISP problems" and "How could I do this?"

> Subject: [LARTC] Small ISP problems (CBQ)
 > First of all, this is what we want (in network priority order):
 > 1: SSH - to be realtime always.
I don''t think you want this to always be high prio - that includes scp.

 > 2: HTTP to be fast, always.
Clearly can''t be done if you have more http requests than your
bandwidth can handle.

 > 3-> ftp, direct-connect, kazaa and others to be throttled to X bandwidh
per
 > IP.. (or not disturb http and ssh and use real fair quing.. )

I think what you really want is to prevent large flows from unfairly
impacting small ones, and that''s what sfq does.  Try it and see
whether you get the behavior you want.

=============== > Subject: [LARTC] How could I do this?

 > If I want to limit bandwidth from a lot of ip addresses( every ip has a
 > limit),
Again, I wonder if this is really what you want.  You really want to
waste extra bandwidth?  Normally if you have 10 users you''d be willing
to let one use all of the bandwidth whenever none of the others want
any.  Now it''s possible for an ISP that you promise some particular
bandwidth to each customer and don''t want to give him more unless he
pays for it.  That''s another situation.
If you''re really in the first situation where you just want to give
equal service to all who are requesting it then what you really want
is a slight variant of sfq.  If you look at the code you''ll see a hash
function that takes into consideration source and destination ip
address and port and maybe other stuff.  All you want to do is remove
all but the source IP (and then perhaps do what you can to prevent
source forgery!).  That will give fair service among all source IP
addresses.

>  > Subject: [LARTC] Small ISP problems (CBQ)
>  > First of all, this is what we want (in network priority order):
>  > 1: SSH - to be realtime always.
> I don''t think you want this to always be high prio - that includes
scp.
your''e right, only the real ssh traffic..
>
>  > 2: HTTP to be fast, always.
> Clearly can''t be done if you have more http requests than your
> bandwidth can handle.
That is a fact yes..
Let me rephrase it then. I don''t want the http traffic to be slowed
down by
for e.g ftp-data traffic...

>  > 3-> ftp, direct-connect, kazaa and others to be throttled to X
> bandwidh per
>  > IP.. (or not disturb http and ssh and use real fair quing.. )
>
> I think what you really want is to prevent large flows from unfairly
> impacting small ones, and that''s what sfq does.  Try it and see
> whether you get the behavior you want.
Oki, I tried it. I defined two classes. "all_in" and
"all_out".
I have 2Mbit full duplex so just to be sure my que isn''t ending up in
the
g703 "modem" I defined the classes to 1,900Mbit downstream and
1,000Mbit
upstream.
Put SFQ on both classes and tested under heavy load..

Well, My ssh isn''t working very well..  :/
>
> ===============>  > Subject: [LARTC] How could I do this?
>
>  > If I want to limit bandwidth from a lot of ip addresses( every ip has
a
>  > limit),
> Again, I wonder if this is really what you want.  You really want to
> waste extra bandwidth?  Normally if you have 10 users you''d be
willing
> to let one use all of the bandwidth whenever none of the others want
> any.  Now it''s possible for an ISP that you promise some
particular
> bandwidth to each customer and don''t want to give him more unless
he
> pays for it.  That''s another situation.
yes it is, the primary is to make sure ssh is always moving fast, http to
and bulk traffic like ftp-data on a low priority, not disturbing the other
two.
> If you''re really in the first situation where you just want to
give
> equal service to all who are requesting it then what you really want
> is a slight variant of sfq.  If you look at the code you''ll see a
hash
function that takes into consideration source and destination ip

What code exactly ? I am currently using the cbq.init script version 0.6.2 .
> address and port and maybe other stuff.  All you want to do is remove
> all but the source IP (and then perhaps do what you can to prevent
> source forgery!).  That will give fair service among all source IP
> addresses.
Ok..

Take a look at this:

Right now my bandwidth looks like this:

Total Rates: 	2170.6 kbits/s
			517.6 packets/sec

Incoming rates:	1769.4 kbits/s
			261.4 packets/sec

Outgoing rates:	401.2 kbits/sec
			256.2 packets/sec

Well, we have a full duplex 2Mbit connection so this should not be a
problem.
Eventhough, we,  based on a 265 packets test, have 28% packet loss witch is
not good.

Since the bandwidh is not close to 1900kbit/s who is the class maximum

"class cbq 1: root rate 1900Kbit (bounded,isolated) prio no-transmit
 Sent 1339557 bytes 1848 pkts (dropped 0, overlimits 0) "

I wonder, will cbq still do prioritization ?
What about the que.. Will it move for e.g ssh always first in the que or
what happens ?
(rtfm.. yep, been doing that, but this is just not easy.. )

My idea was to have a "mother" cbq class, cbq.0010.everything_in,
defined by
me, doing SFQ on everything. The RULE is for the whole network, like
10.0.0.0/24.
A doughter class to that is cbq.0065.ssh_in.

The thing though is that the ssh_in class never gets any data. Probably
since rule of the mother class always triggers on the packet and it''s
never
being sent down to the ssh class.
If I define the ssh class outside the "everything_in" class, and gives
it a
classid thats lover then the everything_in class it gets data though.
The quality of the ssh link doesn''t seem to change though..
Hmmz.. I''m starting to think that we might have some problem somewhere
else
in the network...

 / Paul