Hello,

Im having an ADSL connection (512/128kbps). When I start mldonkey
webbrowsing is practically impossible, though no dl/ul occurs in
mldonkey just usual seeking for sources, connecting to servers. But if I
start a download (ftp/http) I still get maximumum download bw. So I
thought it must be an upload problem and configured a router with
traffic shaping.
TCng script: http://www.fraenkel.at/bandwidth.tcng

Of course I changed the gateways/dflt routes of all clients in the
network to use the traffic shaping router and mldonkey traffic is now
routed through the class 'download' with a max. of 8kbps - verified
through analyzing network traffic and tc stats and the other classes are
working either.
But webbrowsing is still that slow, until I shutdown mldonkey again.


Here's the topology of my network: http://www.fraenkel.at/topology.txt
Because the Traffic shaping router and the router to the uplink are on
the same subnet traffic flows like that:
Outgoing: Client --> Traffic Shaping Router ---> Router ---> Internet
Incoming: Internet ---> Router ---> Client
/*effectively not using the Traffic shaping router, but that's fine
because I just want to limit upload bw*/

I think it's not Linux specific but I have no idea what to do next,
proposals desired!

Thank you in advance, Benjamin

[ Post a follow-up to this message ]

Benjamin Fraenkel wrote:
> Hello,
>
> Im having an ADSL connection (512/128kbps). When I start mldonkey
> webbrowsing is practically impossible, though no dl/ul occurs in
> mldonkey just usual seeking for sources, connecting to servers. But
if I
> start a download (ftp/http) I still get maximumum download bw. So I
> thought it must be an upload problem and configured a router with
> traffic shaping.
> TCng script: http://www.fraenkel.at/bandwidth.tcng
>
> Of course I changed the gateways/dflt routes of all clients in the
> network to use the traffic shaping router and mldonkey traffic is now

> routed through the class 'download' with a max. of 8kbps - verified
> through analyzing network traffic and tc stats and the other classes
are
> working either.
> But webbrowsing is still that slow, until I shutdown mldonkey again.
>
> Here's the topology of my network:
http://www.fraenkel.at/topology.txt
> Because the Traffic shaping router and the router to the uplink are
on
> the same subnet traffic flows like that:
> Outgoing: Client --> Traffic Shaping Router ---> Router ---> Internet
> Incoming: Internet ---> Router ---> Client
> /*effectively not using the Traffic shaping router, but that's fine
> because I just want to limit upload bw*/
>
> I think it's not Linux specific but I have no idea what to do next,
> proposals desired!

Well, SFQ is not very insistent -- assumes everyone is playing "fair"
in order to get the F queueing.

http://www.tldp.org/HOWTO/Traffic-C...scs.html#qs-sfq
[q]
Unfortunately, some clever software (e.g. Kazaa and eMule among others)
obliterate the benefit of this attempt at fair queuing by opening as
many TCP sessions (flows) as can be sustained.
[eq]

These hummers are difficult to control.  For what you're trying to
accomplish, you might want to look at this:
http://mldonkey.berlios.de/modules....=TrafficShaping

The key to its working is the use of the UID of mldonkey so that the
dynamically allocated flows can be marked/identified for control
purposes.  This also means that it only works on the machine running
mldonkey as the fwmarks are strictly "machine local".

Don't use any of the p2p apps so haven't any direct experience.  The
above approach looks promising from my read-through.  Just squashing
them whem found at work.

Someone around here likely has more experience and perhaps a ready-made
solution or specific guidance dealing with mldonkey in a setup like
yours.  The problem is identifying/distinquishing all the p2p ports
being used.

With your network setup, it is _imperative_ that all machines/nics be
operating at top speed/full duplex (100 Mbps probably).  The full
duplex is most important.

hth,
prg
email above disabled

[ Post a follow-up to this message ]

prg wrote:
> Benjamin Fraenkel wrote:
> 
>
> if I
> 
>
> 
>
> are
> 
>
> http://www.fraenkel.at/topology.txt
> 
>
> on
> 
>
>
> Well, SFQ is not very insistent -- assumes everyone is playing "fair"
> in order to get the F queueing.
In the same class only. But my WWW Traffic has it's own class with a
guaranteed min bw of 60kbps. (Of course there can still be contention
between the classes because their accumulated min. bw exceeds the
overall maximum, but still the download class is limited to a max. of
8kbps).
>
> http://www.tldp.org/HOWTO/Traffic-C...=TrafficShaping
>
> The key to its working is the use of the UID of mldonkey so that the
> dynamically allocated flows can be marked/identified for control
> purposes.  This also means that it only works on the machine running
> mldonkey as the fwmarks are strictly "machine local".
>
> Don't use any of the p2p apps so haven't any direct experience.  The
> above approach looks promising from my read-through.  Just squashing
> them whem found at work.
>
> Someone around here likely has more experience and perhaps a ready-made
> solution or specific guidance dealing with mldonkey in a setup like
> yours.  The problem is identifying/distinquishing all the p2p ports
> being used.
>
I don't care if there's no fair queuing in the download class, because
the only apps that are using it are p2p programms ;)
And I don't need to filter by UID on the mldonkey-machine though I don't
know the exact port numbers, because I know the port numbers of
"programms" I want to prioritize (WWW, E-Mail, SSH), the bulk (mldonkey)
goes to the download class.
> With your network setup, it is _imperative_ that all machines/nics be
> operating at top speed/full duplex (100 Mbps probably).  The full
> duplex is most important.
I run at full duplex (in reality it's a switched network, me just a lazy
guy ;). I don't understand your objection, because the bw-limiting only
occurs for traffic destined for the uplink, local traffic travels at
full-duplex.
>
> hth,
> prg
> email above disabled
>
Regards.

[ Post a follow-up to this message ]

Benjamin Fraenkel wrote:
[snip]

I was busy yesterday and thought someone else might have posted by now.

My post was meant to:
a) make sure you weren't simply trying out some scipt you had picked up
from somewhere, anywhere
b) provide you with an alternative that did not require QoS shaping at
a central point as your drawing showed
c) keep it as simple as possible ;-)

Your current set up really won't have any effect till the pipe/queues
begin to fill up.  Till then it's just a large SFQ scheduler.  Entails
added latency (compared to Linux w/o p2p running and using its default
queue) and has no prios set up to prioritize traffic.

Even then you have to size your queue(s) so that _they_ don't overflow
the upstream queues -- like your switch or (most likely) dsl modem if
it queues packets (which most do, IIRC, especially for upload).
Effectively clamps the bandwidth available at the shaping point.  Not
good for intra-lan traffic.

My comment about SFQ's inablilty to help much comes from experience of
students in the lab as well as the author of HTB.
http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm

Any filestreaming through HTB is problematic for other protocols,
especially those that send a number of short packets back-n-forth.  SFQ
only assures that these smaller packets will get _some_ benefit when
competeing for bandwidth/scheduling -- ie., won't get "locked out".
SSH and telnet users usually remain unhappy campers.  HTML can also be
a pain with DNS and multiple uri accesses required for most pages these
days.  Ditto SMTP.

Now you _could_ keep playing with this and incorporate a priority qdisc
into the structure.  But that can get _really_ tricky when running a
number of different prototcols and requires that you play with the
higher priority queue lengths, else the higher priority traffic will
block lower priority traffic entirely.
http://www.opalsoft.net/qos/DS-23.htm
http://www.docum.org/docum.org/docs/

There are two projects that have ready-made approaches, more or less,
for clamping p2p clients at a router/switch.  IPP2P seems the most used
and l7-filter needs lots of hand feeding.

http://www.ipp2p.org/
http://l7-filter.sourceforge.net/

Haven't checked at netfilter.org for patch-o-matic solutions or
reviewed any scripts lately.
http://www.netfilter.org/patch-o-matic/pom-extra.html

Every couple of years I give the bored students in the computer (Linux)
lab classes the challenge of bandwidth limiting/blocking p2p software.
It provides very interesting (and disappointing) results as the "users"
battle the "admins" -- users always find a way ;-0.  It's also a good
way to test software solutions for effectiveness and usability.

hth and good luck,
prg
email above disabled

[ Post a follow-up to this message ]

Benjamin Fraenkel wrote:

> Hello,
>
> Im having an ADSL connection (512/128kbps). When I start mldonkey
> webbrowsing is practically impossible, though no dl/ul occurs in
> mldonkey just usual seeking for sources, connecting to servers. But if I
> start a download (ftp/http) I still get maximumum download bw. So I
> thought it must be an upload problem and configured a router with
> traffic shaping.
> TCng script: http://www.fraenkel.at/bandwidth.tcng

I never got into tcng - can you get it to dump the tc output.

With tc bps means bytes per second - I think it's bits for tcng, you can
double check with tc -s -d class ls dev eth0.

As Prg says sfq is best for bulk really (though your point about it being
classified allready by htb is valid). Also again as Prg suggests you ought
to use some extra htb parameters - prio, quantum, burst and cburst to tweak
things up for small packets.

It does look like your setup should work at first glance, so it should be
fixable.


Andy.

[ Post a follow-up to this message ]

...
> Your current set up really won't have any effect till the pipe/queues
> begin to fill up.  Till then it's just a large SFQ scheduler.  Entails
> added latency (compared to Linux w/o p2p running and using its default
> queue) and has no prios set up to prioritize traffic.
Hmm you seem to be right, though I can't follow. At least the
download-class (p2p-traffic) queue fills up and drops packets.
> Even then you have to size your queue(s) so that _they_ don't overflow
> the upstream queues -- like your switch or (most likely) dsl modem if
> it queues packets (which most do, IIRC, especially for upload).
> Effectively clamps the bandwidth available at the shaping point.  Not
> good for intra-lan traffic.
Regarding the upstream queues. I limited the max. bw to 80kbps (even
tried with 60) though I got 128kbps upstream, so my modem shouldn't
queue anything.
>
> My comment about SFQ's inablilty to help much comes from experience of
> students in the lab as well as the author of HTB.
> http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm
>
> Any filestreaming through HTB is problematic for other protocols,
> especially those that send a number of short packets back-n-forth.  SFQ
> only assures that these smaller packets will get _some_ benefit when
> competeing for bandwidth/scheduling -- ie., won't get "locked out".
> SSH and telnet users usually remain unhappy campers.  HTML can also be
> a pain with DNS and multiple uri accesses required for most pages these
> days.  Ditto SMTP.
But again, I thought if I put WWW-traffic into another class with an
assured bw, I would have no problems. Please correct me, because I'm
feeling quite dumb now as nothing works.
>
> Now you _could_ keep playing with this and incorporate a priority qdisc
> into the structure.  But that can get _really_ tricky when running a
> number of different prototcols and requires that you play with the
> higher priority queue lengths, else the higher priority traffic will
> block lower priority traffic entirely.
> http://www.opalsoft.net/qos/DS-23.htm
> http://www.docum.org/docum.org/docs/
I'm quite sure it would work with a prio qdisc. But at first I wanted to
use the 'prio' option with htb classes but it had no effect?
>
> There are two projects that have ready-made approaches, more or less,
> for clamping p2p clients at a router/switch.  IPP2P seems the most used
> and l7-filter needs lots of hand feeding.
>
> http://www.ipp2p.org/
> http://l7-filter.sourceforge.net/
Great just what I needed, thanks! But with that I can also 'just'
classify (or drop) the p2p traffic, not bw-limiting it. I would have to
use  htb again, putting it into the download-class, and would have the
same problems again, it would be just a bit more fine-grained?
...
TIA Benjamin

[ Post a follow-up to this message ]

Benjamin Fraenkel wrote:
> ... 
pipe/queues[vbcol=seagreen] 
Entails[vbcol=seagreen] 
default[vbcol=seagreen] 
> Hmm you seem to be right, though I can't follow. At least the
> download-class (p2p-traffic) queue fills up and drops packets.

If packets aren't delayed going out they may "overflow" the receive
and/or transmit buffer of upstream device, thus dropping packets,
requiring a retransmit and window size adjustment -- perhaps to zero,
effectively restarting the slow start process all over again.
 
overflow[vbcol=seagreen] 
if[vbcol=seagreen] 
Not[vbcol=seagreen] 
> Regarding the upstream queues. I limited the max. bw to 80kbps (even
> tried with 60) though I got 128kbps upstream, so my modem shouldn't
> queue anything.

I'm still not sure why you are doing this.  The whole point of HTB is
to make "most effecient" use of _all_ available bandwidth.  Your setup
deprives you of 48 kbps.
 
of[vbcol=seagreen] 
SFQ[vbcol=seagreen] 
when[vbcol=seagreen] 
be[vbcol=seagreen] 
these[vbcol=seagreen] 
> But again, I thought if I put WWW-traffic into another class with an
> assured bw, I would have no problems. Please correct me, because I'm
> feeling quite dumb now as nothing works.

The HTB param entries are _at_best_ a way of effecting _average_
performance, not a packet-by-packet guarantee.  SFQ emphasizes this
average aspect.  It's a "cheap" algorithm meant to give smaller packets
a chance to be queued more "appropriately" than they would be queued by
FIFO.
 
qdisc[vbcol=seagreen] 
a[vbcol=seagreen] 
will[vbcol=seagreen] 
> I'm quite sure it would work with a prio qdisc. But at first I wanted
to
> use the 'prio' option with htb classes but it had no effect?

It's not a bad idea to go step-by-step to get an idea of what effect
the different additions will have.  In fact, it's probably the best way
to get a good idea of how _any_ of the qdiscs work.
 
less,[vbcol=seagreen] 
used[vbcol=seagreen] 
> Great just what I needed, thanks! But with that I can also 'just'
> classify (or drop) the p2p traffic, not bw-limiting it. I would have
to
> use  htb again, putting it into the download-class, and would have
the
> same problems again, it would be just a bit more fine-grained?

Well, what you use will depend on what you want to accomplish.  The
docs re: qdiscs is rather sparse and scattered.  Most people learn by
experimenting and monitoring the traffic flows as they try different
things.  Probably most folks settle on something that seems to work
"good enough" and let it go at that.  Or use a "pre-canned" solution.

The HTB user guide, the lartc Advanced Routing Howto, and the following
are the best starting place I know:
http://linux-ip.net/html/
http://lartc.org/howto/
http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm

The ultimate goal is to have a path that fully utilizes the available
bandwidth _without_ requiring retransmits and constantly changing
window sizes in the TCP session.  And remember that TCP requires ACKs
which are themselves small packets mingled within all sessions for any
protocol.

Your current setup is more prone to effecting net performance as the
QoS box is managing all bandwidth as well as its own traffic and the TX
queue is constantly worked.

good luck,
prg
email above disabled

[ Post a follow-up to this message ]

prg wrote:


> Every couple of years I give the bored students in the computer (Linux)
> lab classes the challenge of bandwidth limiting/blocking p2p software.
> It provides very interesting (and disappointing) results as the "users"
> battle the "admins" -- users always find a way ;-0.  It's also a good
> way to test software solutions for effectiveness and usability.

I suppose now hfsc is in the kernel things could be easier (not blocking),
but in theory you can now do things properly per user, which was hard with
htb. Though they could still spoof MAC addresses I suppose.

Andy.

[ Post a follow-up to this message ]

Hello,

I'm sorry I didn't answer, but had/have some problems.
After messing up netfilter with broken pom-patches I finally got ipp2p
installed but as I assumed it didn't solve anything.
I also tweaked htb options prio, burst, cburst - no effect, followed the
instructions from
http://gentoo-wiki.com/HOWTO_Packet_Shaping

Now I set up a priority queue to prioritize every but ipp2p traffic, but
still after starting the p2p client WWW-Traffic freezes, here's my script:
http://fraenkel.at/ng.sh.txt

I hope there's something totally wrong with the script. I also tried
ready-made scripts including wondershaper but nothing worked.

TIA, Benjamin

[ Post a follow-up to this message ]