[LARTC] DSCP, ToS and Egress

[LARTC] DSCP, ToS and Egress

[Dan Cox]

I'm successfully using HTB + GRED to shape traffic based on the DSCP field. I
would like to strip the DSCP and possibly replace it with normal ToS bits on
egress traffic leaving my network. Leaving DSCP set is pointless, and could
potentially cause problems with some ISPs that use DSCP internally I suppose.
Setting ToS bits would seem ideal as most networks still honor it to varying
degrees.

The problem is I can see no way of doing this. Since DSCP is needed in the
qdiscs for shaping, it can't be mangled with iptables. According to the packet
flow diagram, there doesn't appear to be any other opportunity to mangle the
packets in this manor. Will I need to insert another router in the chain just
to do this? :(

-- 
Dan-
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] DSCP, ToS and Egress

[Catalin(ux aka Dino) BOIE]

On Tue, 15 Feb 2005, Dan Cox wrote:

> I'm successfully using HTB + GRED to shape traffic based on the DSCP field. I
> would like to strip the DSCP and possibly replace it with normal ToS bits on
> egress traffic leaving my network. Leaving DSCP set is pointless, and could
> potentially cause problems with some ISPs that use DSCP internally I suppose.
> Setting ToS bits would seem ideal as most networks still honor it to varying
> degrees.
>
> The problem is I can see no way of doing this. Since DSCP is needed in the
> qdiscs for shaping, it can't be mangled with iptables. According to the packet
> flow diagram, there doesn't appear to be any other opportunity to mangle the
> packets in this manor. Will I need to insert another router in the chain just
> to do this? :(

You can clone the GRED qdisc code and modify it to overwrite the DSCP 
bits.

>
> -- 
> Dan-
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>

---
Catalin(ux aka Dino) BOIE
catab at deuroconsult.ro
http://kernel.umbrella.ro/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] DSCP, ToS and Egress

[George Alexandru Dragoi]

You can try with IMQ, which probably is not wanted for a production
server. You can also mark the pachets which have some DSCP bits, then
use u32 with the mark match (Probably Catalin's implementation), i
think it is even in some latest 2.6 kernels, also don't forget to use
a new iproute2 :)


On Wed, 16 Feb 2005 11:12:46 +0200 (EET), Catalin(ux aka Dino) BOIE
<util@deuroconsult.ro> wrote:
> On Tue, 15 Feb 2005, Dan Cox wrote:
> 
> > I'm successfully using HTB + GRED to shape traffic based on the DSCP field. I
> > would like to strip the DSCP and possibly replace it with normal ToS bits on
> > egress traffic leaving my network. Leaving DSCP set is pointless, and could
> > potentially cause problems with some ISPs that use DSCP internally I suppose.
> > Setting ToS bits would seem ideal as most networks still honor it to varying
> > degrees.
> >
> > The problem is I can see no way of doing this. Since DSCP is needed in the
> > qdiscs for shaping, it can't be mangled with iptables. According to the packet
> > flow diagram, there doesn't appear to be any other opportunity to mangle the
> > packets in this manor. Will I need to insert another router in the chain just
> > to do this? :(
> 
> You can clone the GRED qdisc code and modify it to overwrite the DSCP
> bits.
> 
> >
> > --
> > Dan-
> > _______________________________________________
> > LARTC mailing list / LARTC@mailman.ds9a.nl
> > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> >
> 
> ---
> Catalin(ux aka Dino) BOIE
> catab at deuroconsult.ro
> http://kernel.umbrella.ro/
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 


-- 
Bla bla
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] DSCP, ToS and Egress

[Dan Cox]

I thought I could use IMQ, but it appears the packets entering the IMQ device
happen last, just like normal device qdiscs. Meaning, you can't send 
packets to
IMQ, then return to iptables for more mangling :/
Also, can't use MARK because I'm already using it for traffic prioritization
across 32 levels, and CLASSIFY is no good for this since it only works on a
leaf class.

I know I can sort traffic with filters, but I don't think it's possible to do
any packet matching and mangling with them? I may have to just modify the
source code :/

Dan-

Quoting George Alexandru Dragoi <waruiinu@gmail.com>:

> You can try with IMQ, which probably is not wanted for a production
> server. You can also mark the pachets which have some DSCP bits, then
> use u32 with the mark match (Probably Catalin's implementation), i
> think it is even in some latest 2.6 kernels, also don't forget to use
> a new iproute2 :)
>
>
> On Wed, 16 Feb 2005 11:12:46 +0200 (EET), Catalin(ux aka Dino) BOIE
> <util@deuroconsult.ro> wrote:
>> On Tue, 15 Feb 2005, Dan Cox wrote:
>>
>> > I'm successfully using HTB + GRED to shape traffic based on the 
>> DSCP field. I
>> > would like to strip the DSCP and possibly replace it with normal 
>> ToS bits on
>> > egress traffic leaving my network. Leaving DSCP set is pointless, 
>> and could
>> > potentially cause problems with some ISPs that use DSCP internally 
>> I suppose.
>> > Setting ToS bits would seem ideal as most networks still honor it 
>> to varying
>> > degrees.
>> >
>> > The problem is I can see no way of doing this. Since DSCP is needed in the
>> > qdiscs for shaping, it can't be mangled with iptables. According 
>> to the packet
>> > flow diagram, there doesn't appear to be any other opportunity to 
>> mangle the
>> > packets in this manor. Will I need to insert another router in the 
>> chain just
>> > to do this? :(
>>
>> You can clone the GRED qdisc code and modify it to overwrite the DSCP
>> bits.
>>
>> >
>> > --
>> > Dan-
>> > _______________________________________________
>> > LARTC mailing list / LARTC@mailman.ds9a.nl
>> > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>> >
>>
>> ---
>> Catalin(ux aka Dino) BOIE
>> catab at deuroconsult.ro
>> http://kernel.umbrella.ro/
>> _______________________________________________
>> LARTC mailing list / LARTC@mailman.ds9a.nl
>> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>>
>
>
> --
> Bla bla
>

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

[LARTC] DSCP, ToS and Egress

[Antonios Halkiopoulos]

On Tue, 15 Feb 2005, Dan Cox wrote:


>> I'm successfully using HTB + GRED to shape traffic based on the DSCP field.
>

I am investigationg WHY HTB + GRED does not work on my test beds. In 
SuSe 9.1 , 9.2 and Debian testing with 2.6.8 and 2.4.27 i face LOTS of 
problems (actually GRED works partially).

Can you sent me your scripts and mention the version's of the kernel and 
iproute2 you are currently using?

Thanks in advance for your time,
Antonios Chalkiopoylos

My only working configuration is vanilla kernel 2.4.20 (patched with HTB)
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] DSCP, ToS and Egress

[Dan Cox]

I would post my scripts but they're around several thousand lines, intertwined
with lots of variable substitution and generate about 300 qdiscs and 
classes so
I don't think it would be easy to follow :)

I'm using stock Fedora Core 3 packages for kernel (2.6.10), iptables and
iproute2 (2.6.9) with the QNET patchset applied
(http://kem.p.lodz.pl/~peter/qnet/). I've also done this under Gentoo with the
same stock kernels, packages and patches.

Basically, I sort traffic into several different HTB classes based on 
protocol,
then I have 4 levels of priority subclasses under each protocol, with yet
another 4 levels of subpriorities under those. IPTables helps here by MARKing
the packets so I know which priority subclass to sort them into. Then I use an
HTB + diffserv combo on these leaf priority subclasses to apply GRED for
AF1-AF4 and apply RED for BE (not using EF yet).

Here is an organizational snippet with 1 protocol priority level:
|root DSMARK qdisc
|root DSMARK bit mask filters
|HTB main qdisc
|HTB main class
|HTB main filters (sort based on protocol into subs)
  |HTB UDP Protocol Subclass
  |HTB UDP Protocol Subclass filters (sort based on MARK value into subs)
   |HTB UDP Priority 1 Subclass
   |HTB UDP Priority 1 filters (apply DSMARK bit mask for sorting into subs)
    |HTB AF1 Class
     |GRED qdisc
    |HTB AF2 Class
     |GRED qdisc
    |HTB AF3 Class
     |GRED qdisc
    |HTB AF4 Class
     |GRED qdisc
    |HTB BE Class
     |RED qdisc

There's a great site with lots of examples and info:
http://www.opalsoft.net/qos/DS.htm

Hope that helps-
Dan-

Quoting Antonios Halkiopoulos <alg0@iit.demokritos.gr>:

> On Tue, 15 Feb 2005, Dan Cox wrote:
>
>
>>> I'm successfully using HTB + GRED to shape traffic based on the DSCP field.
>>
>
> I am investigationg WHY HTB + GRED does not work on my test beds. In 
> SuSe 9.1 , 9.2 and Debian testing with 2.6.8 and 2.4.27 i face LOTS 
> of problems (actually GRED works partially).
>
> Can you sent me your scripts and mention the version's of the kernel 
> and iproute2 you are currently using?
>
> Thanks in advance for your time,
> Antonios Chalkiopoylos
>
> My only working configuration is vanilla kernel 2.4.20 (patched with HTB)
>



-- Dan-

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] DSCP, ToS and Egress

[Antonios Halkiopoulos]

Dan Cox wrote:

> I would post my scripts but they're around several thousand lines, 
> intertwined
> with lots of variable substitution and generate about 300 qdiscs and 
> classes so
> I don't think it would be easy to follow :)

I am still interested, just post them to my personal email only so that 
you won't flood lartc list.

> I'm using stock Fedora Core 3 packages for kernel (2.6.10), iptables and
> iproute2 (2.6.9) with the QNET patchset applied
> (http://kem.p.lodz.pl/~peter/qnet/). I've also done this under Gentoo 
> with the same stock kernels, packages and patches.

I will check as soon as possible
 

>    |HTB AF1 Class
>     |GRED qdisc
>    |HTB AF2 Class
>     |GRED qdisc
>    |HTB AF3 Class
>     |GRED qdisc
>    |HTB AF4 Class
>     |GRED qdisc
>    |HTB BE Class
>     |RED qdisc


This is the part i am most interested in. I guess GRED for AF1 (for 
example) takes care of AF11 , AF12, AF13 and AF14. If so please sent me 
your scripts.

I will generate UDP traffic with mgen to test the kernels i am currently 
using.

Thanks for your time,
Antonios Chalkiopoulos
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] DSCP, ToS and Egress

[Dan Cox]

[-- Attachment #1: Type: text/plain, Size: 2590 bytes --]

I've attached my diffserv automagic generator script because I think 
it's pretty
useful. Any feedback appreciated. After sourcing this into your scripts you
basically feed it the following information to have it auto generate 
the needed
classes and qdiscs based on formulas I've found on the net. This should be
called to attach itself to a leaf class when you are already done sorting
traffic into generic priority queues, etc. Note that I've ripped this out of a
much larger script, but it should work as is.

Here's an example of the arguments the 'diffserv' function takes:
# -----------------------------------------------
# PARENT:   Parent Class ID
# DEV:      Target Device
# RATE:     Parent Rate                 (kbit)
# CEIL:     Parent Ceiling              (kbit)
# AVPKT:    Average Packet Size         (bytes)
# LATENCY:  Target Latency              (milliseconds)
# QUANTUM:  Device MTU (normally)       (bytes)
# MTU:      Maximum Transmission Unit   (bytes)
# MPU:      Minimum Packet Unit         (bytes)
# OVERHEAD: Packet Overhead             (bytes)
# -----------------------------------------------

The most common problem someone will run into with this script is not 
being able
to guarantee a low enough latency. It takes a certain amount of 
bandwidth (rate)
to guarantee a target latency based on the average packet size (of course!).

Dan -

Quoting Antonios Halkiopoulos <alg0@iit.demokritos.gr>:

> Dan Cox wrote:
>
>> I would post my scripts but they're around several thousand lines, 
>> intertwined
>> with lots of variable substitution and generate about 300 qdiscs and 
>> classes so
>> I don't think it would be easy to follow :)
>
> I am still interested, just post them to my personal email only so 
> that you won't flood lartc list.
>
>> I'm using stock Fedora Core 3 packages for kernel (2.6.10), iptables and
>> iproute2 (2.6.9) with the QNET patchset applied
>> (http://kem.p.lodz.pl/~peter/qnet/). I've also done this under 
>> Gentoo with the same stock kernels, packages and patches.
>
> I will check as soon as possible
>
>
>>    |HTB AF1 Class
>>     |GRED qdisc
>>    |HTB AF2 Class
>>     |GRED qdisc
>>    |HTB AF3 Class
>>     |GRED qdisc
>>    |HTB AF4 Class
>>     |GRED qdisc
>>    |HTB BE Class
>>     |RED qdisc
>
>
> This is the part i am most interested in. I guess GRED for AF1 (for 
> example) takes care of AF11 , AF12, AF13 and AF14. If so please sent 
> me your scripts.
>
> I will generate UDP traffic with mgen to test the kernels i am 
> currently using.
>
> Thanks for your time,
> Antonios Chalkiopoulos
>



-- Dan-


[-- Attachment #2: diffserv.sh --]
[-- Type: application/x-sh, Size: 10803 bytes --]

Re: [LARTC] DSCP, ToS and Egress

[Dan Cox]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

I've added a few more helper functions for a more complete demonstration. I've
also added some suggested default values (see script).
Here's an example usage for a 100mbit LAN:

# Load the functions into the environment
#
source diffserv.sh
#
# Set device queue length and MTU
#
init_device eth1 10 1500
#
# Clear the device qdiscs
#
reset_qdisc eth1
#
# Create the root DSMARK qdisc & filters.
#
init_classifier eth1 10:
#
# Now create our main HTB qdisc
# We attach to the parent DSMARK qdisc (10:) and give ourselves a handle of 1:
#
qdisc eth1 "parent 10: handle 1: htb default 1 r2q 1"
#
# Now we create our leaf HTB + GRED classes and qdiscs to perform diffserv
# Note that this will create HTB classes underneath the HTB qdisc (1:)
#
diffserv 1: eth1 100000 100000 1000 10 1500 1500 64 0

In a more complex setup, you can insert additional levels of HTB classes under
the HTB qdisc and then call 'diffserv' on those leaf classes, but remember to
add additional filters (can NOT use iptables CLASSIFY target) or traffic will
never reach those classes. 'diffserv' assumes traffic has already made 
it as far
as its parent qdisc (or class) and attaches it's filters there.

Dan-


[-- Attachment #2: diffserv.sh --]
[-- Type: application/x-sh, Size: 14234 bytes --]

Re: [LARTC] DSCP, ToS and Egress

[Jonathan Lynch]

I was just looking at your QoS Script. Did you ever notice that no
packets will be put into gred dp3 ? 

I was using a similar script based on AF examples on the web and
apparently in the gred qdisc now when you declare 3 dps they are
numbered 0,1,2 and not 1,2,3.

This line in gred_enqueue in sch_gred.c will prevent packets that you
have given a tcindex of 113,123,133,143 of being put in the right dp. 
They will get put into the default dp.

if ( ((skb->tc_index&0xf) > (t->DPs -1)) || !(q=t->tab[skb-
>tc_index&0xf])) {

This isnt a bug in the code either as I found out. 

You could take the -1 out of this line or else use gred DP0 , DP1, DP2
and change your tcindex classifiers to 110,111,112

Jonathan

On Fri, 2005-02-18 at 11:25 -0600, Dan Cox wrote:
> I've added a few more helper functions for a more complete demonstration. I've
> also added some suggested default values (see script).
> Here's an example usage for a 100mbit LAN:
> 
> # Load the functions into the environment
> #
> source diffserv.sh
> #
> # Set device queue length and MTU
> #
> init_device eth1 10 1500
> #
> # Clear the device qdiscs
> #
> reset_qdisc eth1
> #
> # Create the root DSMARK qdisc & filters.
> #
> init_classifier eth1 10:
> #
> # Now create our main HTB qdisc
> # We attach to the parent DSMARK qdisc (10:) and give ourselves a handle of 1:
> #
> qdisc eth1 "parent 10: handle 1: htb default 1 r2q 1"
> #
> # Now we create our leaf HTB + GRED classes and qdiscs to perform diffserv
> # Note that this will create HTB classes underneath the HTB qdisc (1:)
> #
> diffserv 1: eth1 100000 100000 1000 10 1500 1500 64 0
> 
> In a more complex setup, you can insert additional levels of HTB classes under
> the HTB qdisc and then call 'diffserv' on those leaf classes, but remember to
> add additional filters (can NOT use iptables CLASSIFY target) or traffic will
> never reach those classes. 'diffserv' assumes traffic has already made 
> it as far
> as its parent qdisc (or class) and attaches it's filters there.
> 
> Dan-
> 

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc