[Mldonkey-bugs] [bug #12471] Add ToS support

[Mark Schreiber]

Follow-up Comment #7, bug #12471 (project mldonkey):

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?

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?func=detailitem&item_id=12471>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/