Re: Alternative section to the HOWTO...

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Javier Ors wrote:
 IMHO, the priomap explanation in the 9.2.1.1. of the LARTC HOWTO is not
clear enough. I only understood it's real behavior until I read this
document from Russell Stuart:
http://ace-host.stuart.id.au/russell/files/tc/doc/tc/priority.txt So, based
in this information, I've prepared an alternative priomap explanation for
this section of the HOWTO, if you like it as it is I could try to do the
modifications to the .db file. If not, just take what you want from it or
forget it... It is possibly full plenty of techical mistakes and also
linux-centered, as long as I have no idea how this goes on other operating
systems. I'm not a professional, so please don't be hard with the
criticism...
   priomap

Determines how packet priorities, as assigned by the kernel, map to bands.

The kernel assigns a generic priority to every packet which enters or is
generated in the machine, this priority is an 8-bit integer, and higher
value means higher priority. The priomap defines how all the 16 possible
values of the linux priority are mapped to the bands.

For example, on the command line, the default priomap looks like this; 1 2 2
2 1 2 0 0 1 1 1 1 1 1 1 1. This means the following mapping:

Linux priority       Default Band (priomap)
--------------       ----------------------
0 (Best Effort)      1
1 (Filler)           2
2                    2
3 (Bulk)             2
4 (Interactive Bulk) 1
5                    2
6 (Interactive)      0
7                    0
8                    1
9                    1
10                   1
11                   1
12                   1
13                   1
14                   1
15                   1

Some of the linux priority values have a symbolic name, but on the table
above only five of them are shown. For IPv4 packets we will only care about
the bands assigned to those five named values. This is beacause for packets
using this protocol, the priority is assigned based on the ToS octet of the
packet, which looks like this:

   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 |                       |     |
|   PRECEDENCE    |          ToS          | MBZ |
|                 |                       |     |
+-----+-----+-----+-----+-----+-----+-----+-----+

The four ToS bits (the 'ToS field') are defined as:

Binary Decimal  Meaning
-----------------------------------------
1000   8         Minimize delay (md)
0100   4         Maximize throughput (mt)
0010   2         Maximize reliability (mr)
0001   1         Minimize monetary cost (mmc)
0000   0         Normal Service

As the MBZ must be zero, the actual value of the ToS field is double the
value of the ToS bits. Tcpdump -v -v shows you the value of the entire ToS
field, not just the four bits. It is the value you see in the first column
of the following table, which shows how the ToS values are mapped to the
five linux priority values mentioned above:

ToS     Bits  Means                    Linux Priority
------------------------------------------------------
0x0     0     Normal Service           0 (Best Effort)
0x2     1     Minimize Monetary Cost   1 (Filler)
0x4     2     Maximize Reliability     0 (Best Effort)
0x6     3     mmc+mr                   0 (Best Effort)
0x8     4     Maximize Throughput      2 (Bulk)
0xa     5     mmc+mt                   2 (Bulk)
0xc     6     mr+mt                    2 (Bulk)
0xe     7     mmc+mr+mt                2 (Bulk)
0x10    8     Minimize Delay           6 (Interactive)
0x12    9     mmc+md                   6 (Interactive)
0x14    10    mr+md                    6 (Interactive)
0x16    11    mmc+mr+md                6 (Interactive)
0x18    12    mt+md                    4 (Int. Bulk)
0x1a    13    mmc+mt+md                4 (Int. Bulk)
0x1c    14    mr+mt+md                 4 (Int. Bulk)
0x1e    15    mmc+mr+mt+md             4 (Int. Bulk)

This mapping is hard-coded and can not be adjusted, only the default priomap
can be changed, to clarify, the whole process for an IPv4 packet would be:

ToS value ------mapping------> Linux Priority ------priomap ------> Band

A few extra comments:

   - The ToS-to-Linux_Priority mapping is made at the very beggining of
   the routing process, even before the packet enters in the iptables chains.
   This means that changing the ToS field of the packet with iptable's "-j
   TOS --set-tos" flags, will not change neither its linux priority nor
   the band it will be assigned to.
   - Also notice that this mapping is not one-to-one, for expample, by
   only adjusting the priomap, it is impossible to assign a packet with ToS
   value 0x00 (Normal Service), to a different band than a packet with ToS 0x02
   (Maximize reliability), as both values are mapped to linux priority 0 (Best
   Effort).
   - At the moment of writing this, the ToS octet of the IPv4 protocol
   has been superseded by the Diffserv Code Point. But the default linux
   priority mapping, and most common applications (ssh, ftp servers, etc...)
   are still using the ToS scheme, however, this may change in the future.


I don't know if bert has time to read the list anymore, as you say LARTC hasn't been updates for ages.

If mailing bert doesn't get anywhere there was talk of a QOS wiki being started on

http://linux-net.osdl.org/

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

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux