bugmldonkey, a multi-networks file-sharing client - Bugs: bug #12471, Add ToS support

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #12471: Add ToS support

Submitter:  Mark Schreiber <mark7>
Submitted:  Sat 26 Mar 2005 08:19:13 PM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Feature request Status:  Fixed
Assigned to:  None Open/Closed:  Closed
Release:  None Release: 
Operating System:  None Binaries Origin:  None
CPU type:  None

Jump to the original submission

Sun 17 Jul 2005 05:26:53 PM UTC, comment #11: 

The DSCP field value assigned to the packets is 0x02, which Ethereal states as unknown. Isn't it 0x08, the scavenger flag?

Anonymous
Sat 16 Jul 2005 03:25:55 AM UTC, comment #10: 

Ugh...I'm moving, spiral, and OSS is being pushed down to the bottom of my priority list, but post-move I actually have to write something to do this for multiple computers anyway, so I can stick that up.  Sorry for the delay on all this -- a move, a camping trip, and some other things have just kind of made weekends tight up here.

I don't own any consumer routers, but I can do the "generic Linux router" solution.

I've been running with the patch with no breakage problems, but it's been strictly background, and I haven't had time to look into it at all -- I think that some connections (probably either inbound or outbound) may not have had maximize throughput set (since I'm seeing some non-maximize-throughput traffic, which could easily be from another app, since it's only about 1% of total traffic).  Either all or the vast bulk of data being sent is correctly set, however.

Again, apologies for the delay, especially with you putting in the effort, but it's just been a bit crazy here.  I'll put in some time as soon as I can get a little more free time available...I've got some WINE patches pending as well.

Many thinks for the work...

Mark Schreiber <mark7>
Sat 25 Jun 2005 12:34:42 AM UTC, comment #9: 

See patch #4127
I think there should be a Wiki page for the correct settings
on routers so users can easily exploit this feature.
Can any of the people who tested the patch here please take care
of this and post the link here and in the patch?

spiralvoice <spiralvoice>
Group administrator
Mon 06 Jun 2005 07:13:31 AM UTC, comment #8: 

at this savannah bug webpage look at attached files at the bottom

Anonymous
Sat 04 Jun 2005 11:43:03 PM UTC, comment #7: 

Ethereal lists the field as part of the DSCP field, which is correct according to the latest RFCs.  Technically, newer RFCs have turned the "ToS" fields into "DSCP".  However, the RFCs also recommend that DSCP behavior be backwards compatible with ToS (especially since the only end-user applications that use the bits use them in ToS fashion).

Basically, my understanding of what DSCP does is say that the bits are intended for use within a single network (so that a router can cram priority information into a packet and still use IPv4-compatible routers to forward that information along the route without worrying about weird priorities being applied to the traffic in transit), and that the data may be changed along the route (as opposed to the original ToS RFC, where the original intent was to have all Internet routers along the route use the ToS bits to help them prioritize traffic as indicated by the originating application).  What DSCP is doing is pretty much exactly what we want -- today, backbone routers totally ignore ToS bits.  Linux boxes with Advanced Routing enabled use ToS to help soft-prioritize traffic, and my script above makes ToS used as hard priority bands (i.e. high priority traffic can starve low priority traffic).  This is pretty much the behavior we want -- we have no reason to want to slow down our packets on the backbone (which ToS won't do on today's Internet) but we want to be able to flag our packets as low- or high-priority on our local network so that the our cable/DSL router can figure out how to use the available bandwidth going out of the cable modem (which is done by any routers supporting ToS).

For those people who have a Linux router on the edge of their network, it's possible to write even more elaborate iptables/tc scripts (a two-layer HTB tree is what I used) that first evenly shares outbound bandwidth between any hosts competing for outbound bandwidth, and then allocates that bandwidth first to high priority packets, then to normal priority, and then to low priority.  The result is that nobody can starve anyone else, but that interactive ssh sessions are allowed to starve mldonkey if ssh and mldonkey are competing at the same time (ssh uses high priority ToS for interactive sessions).  I don't know of any commercial routers that currently do this advanced two-level structure, though -- probably all you can expect to get pre-done for you is basic Advanced Routing prioritization of ToS bits.

If the concern is simply a way to test whether things are working right, grab yourself a Linux box and run the script (minus the last line) in my bug report on it, and type "tc -s -d class show dev eth0" -- high priority traffic will show up in 1:10, normal in 1:20, and low in 1:30.  Plus, if you open the mldonkey upload floodgates, web browsing should still be snappy on that box.  :-)

I tried testing 572, but could not apply, and I'm not sure where to get 2iptos.patch1...is this available on an FTP site or something?

Mark Schreiber <mark7>
Sat 04 Jun 2005 10:10:54 AM UTC, comment #6: 

according to ethereal the patch isnt working as the tos field is missing

Anonymous
Tue 31 May 2005 08:32:36 AM UTC, comment #5: 

some way to test if it works properly is needed, but it definetly compiles and runs

Anonymous
Mon 30 May 2005 09:17:39 PM UTC, comment #4: 

2iptos.patch1 compiles, any news about it?

spiralvoice <spiralvoice>
Group administrator
Sun 22 May 2005 04:24:34 PM UTC, comment #3: 

patch fails to compile

Anonymous
Sun 22 May 2005 04:21:09 PM UTC, comment #2: 

modified patch 572 with advice from pango
http://savannah.nongnu.org/patch/?func=detailitem&item_id=572

will be testing it

Anonymous
Tue 19 Apr 2005 03:20:55 AM UTC, comment #1: 

The last line should read "--set-tos Maximize-Throughput", not "--set-tos Maximize-Throughpu"

Mark Schreiber <mark7>
Sat 26 Mar 2005 08:19:13 PM UTC, original submission:  

IP provides a mechanism for flagging packets as Maximize-Throughput (bulk) or Minimize-Latency (interactive).  If applications that "soak up extra bandwidth" flag their packets as bulk, it can be extremely useful for bandwidth allocation on residential ADSL or cable routers, and allow users to run P2P 24/7 using all available extra bandwidth -- web browsing and the like is not affected by P2P use.

Mldonkey could provide the option to flag all of its connections as bulk.  The main problem is that the current version of ocaml does not expose the required flags.

In C, flagging connections as bulk is done with these simple two lines of code:

int tos = IPTOS_THROUGHPUT;
setsockopt(sock, IPPROTO_IP, IP_TOS, (char *)&tos, sizeof(tos));

IPPROTO_IP and IP_TOS are not exposed by ocaml, so mldonkey cannot use this line.

A fix would entail adding IPPTORO_IP and IP_TOS to ocaml, and then locating all the places that sockets are created in mldonkey and setting them to bulk (if the user so desires).

Those mldonkey users who are on Linux boxes can enjoy this functionality already, without application-level support.  The following configuration should work nicely out-of-box for those of you with a single computer (no NATTing routers set up or anything fancy like that) connected to an ADSL or cable line:

Simply use the following commands:

groupadd mlnet
chgrp mlnet mlnet (in the mldonkey directory, as root)
chmod g+s mlnet (in the mldonkey directory, as root)

Then use the following script (adjust the variables at the top to fit your particular configuration):

#!/bin/bash

DEV=eth0

RATE=370kbit
HIGH_RATE=200kbit
MED_RATE=100kbit
LOW_RATE=20kbit

# if there are already traffic-shaping rules in place, this removes them
# this will print an error if they don't exist, but continue to work
tc qdisc del dev $DEV root

tc qdisc add dev $DEV root handle 1: htb default 20

# PARENT CLASS
tc class add dev $DEV parent 1: classid 1:1 htb rate $RATE

# CHILD CLASSES
tc class add dev $DEV parent 1:1 classid 1:10 htb rate $HIGH_RATE ceil $RATE
tc class add dev $DEV parent 1:1 classid 1:20 htb rate $MED_RATE ceil $RATE quantum 1500
tc class add dev $DEV parent 1:1 classid 1:30 htb rate $LOW_RATE ceil $RATE quantum 1500

# interactive
tc filter add dev $DEV parent 1: prio 1 protocol ip u32 match ip tos 0x10 0x18 flowid 1:10
# bulk
tc filter add dev $DEV parent 1: prio 1 protocol ip u32 match ip tos 0x08 0x18 flowid 1:30

# make p2p bulk
iptables -t mangle -A OUTPUT -m owner -p tcp --gid-owner mlnet -j TOS --set-tos Maximize-Throughpu

Mark Schreiber <mark7>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #3006:  2iptos.patch1 added by None (3KiB - application/octet-stream - updated compiling and working patch ( 99% from pango ))
file #3005:  tos.patch added by None (2KiB - text/x-patch - modified patch 572)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 5 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-07-08 spiralvoice StatusNone Fixed
    Open/ClosedOpen Closed
2005-05-23 None Attached File- Added 2iptos.patch1, #2535
2005-05-22 None Attached File- Added tos.patch, #2531
2005-04-18 spiralvoice PrivacyPrivate Public

Back to the top

Powered by Savane 3.13-3230.
Corresponding source code