Re: [Mldonkey-users] Traffic shaping

[Goswin Brederlow]

Martin Kuhlmann <address@hidden> writes:

> Hi,
> 
>   I'm running mldonkey 2.02-0 on my server, which is also my default
>   gateway for two other systems and provides the access to the
>   internet through german T-DSL.
> 
>   Since mldonkey is set to 10 kb upload and thus uses around 14 or 15
>   with tendency to use all while i'm trying to do anything other i set
>   up traffic shaping.
> 
>   So long it doesn't do what it should. Sure, i can set mldonkey to
>   use only 3kb upload, 8kb or all of the 128 kbit if it's not needed
>   anywhere else... but thats effecting not only the upload to other
>   clients.
> 
>   OK. I shape the outgoing to 120 kbit max. I wanted to put mldonkey
>   in a class with lowest priority to let him work only when I don't
>   need the bandwidth. That way it would be possible to let him upload
>   as much as he can, not the 10kb max most people use.
> 
>   But the minute I start the traffic shaping, my downloadrates goes
>   down from >= 10kb to less than 1kb. What i think might be happen is
>   this: Due to too much traffic packets will be dropped. We only know
>   that this packets are from mldonkey. It could be mldonkey talking
>   with other clients to upload or download something, mldonkey talking
>   to a server or simply uploading data to others.

I use the following:

1. QoS scheduling

  root --- HTB 128 KBit limit which dsl has here
             |
             +-- 126 - 128 KBit normal traffic
             +--   1 -  64 KBit SYN/ACK/FIN/RST mldonkey connects
             +--   1 -  64 KBit mldonkey data

I filter out mldonkey traffic by UID (i have an mldonkey user) and
tcp-flags and mark them. The mark is then used for sorting into the
traffic shaping queues.

======================================================================
#! /bin/sh

set -evx

logger "firewall: initializing for $IFNAME (local IP $IPLOCAL, DNS servers 
$DNSSERVERS)"

# --- shaping ----------------------------------------------------------
tc qdisc del dev $IFNAME root || true

tc qdisc add dev $IFNAME root handle 1: htb default 10
tc class add dev $IFNAME parent 1: classid 1:1 htb rate 128kbit burst 2k
tc class add dev $IFNAME parent 1:1 classid 1:10 htb rate 126kbit ceil 128kbit 
burst 2k
tc class add dev $IFNAME parent 1:1 classid 1:20 htb rate 1kbit ceil 64kbit 
burst 2k
tc class add dev $IFNAME parent 1:1 classid 1:30 htb rate 1kbit ceil 64kbit 
burst 2k
tc qdisc add dev $IFNAME parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $IFNAME parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev $IFNAME parent 1:30 handle 30: sfq perturb 10
tc filter add dev $IFNAME parent 1:0 protocol ip prio 1 handle 4 fw classid 1:20
tc filter add dev $IFNAME parent 1:0 protocol ip prio 1 handle 5 fw classid 1:30

## mark mldonkey for shaping
iptables -t mangle -A OUTPUT -m owner --uid-owner 1003 -j MARK  --set-mark 4
iptables -t mangle -A OUTPUT -p tcp --tcp-flags SYN,ACK,FIN,RST NONE -m owner 
--uid-owner 1003 -j MARK  --set-mark 5
======================================================================

Further I have mldonkey usually limited to 4-6 KB/s upload, which
gives about 8 KB/s up traffic.

>   So, the solution is to use some sort of pattern to let the traffic
>   shaper know what type this packet is. The traffic shaper could
>   classify the mldonkey-packets more exactly and drop only packets we
>   can drop. Thats for example the upload (only the data, not the
>   chatting) to other clients.
> 
>   One way to implement this is to use source and destination port.
>   That i tried already, but it failed. The
>   client-2-client-communication consists of:
> 
>    - To upload something to someone else this client contacts us first
>      on our open port (tcp 4662). We send him datapackets which source
>      port is our donkeyport as an answer to his port, so the
>      destination port will be somewhat higher and random.
>      So I thought we can catch the upload this way.
> 
>    - To download something from someone else we contact him on his
>      open port (tcp 4662). So here it is his open port (tcp 4662) and
>      we get his replys on one of our higher ports.
> 
>   I tried this but it failed. So, what have i missed? How do I get it
>   to work?

The solution would be for mldonkey to realy only send out X Byte/s and
priotise internally. It should send less than X B/s uploads if it
already used 2 KB for searching and connects. But mldonkey should not
just stop sending when X KB has been sent but priotize on what to
send. Send chat first, block requests and searches next and only at
the very end uploads.

MfG
        Goswin